Hey Everyone, Hey Scawen.

I know you have to see lots of messages like that. But I really think it would be great if you can keep us up to date with your progress on the graphics update. It's been so many years now that we are waiting for the update and at least a little note á la "Next progress report will be out in within two months" or "graphics update test patch will be the next available update this year" would make a huge difference to our patience .

I know, that you probably are not able to tell us an exact date or even months when it will be finished, but if possibly in any way, please keep us updated and tell us whats left before you can publish the first beta. I know so many active players that don't even believe you are still working on it - and thats so sad because i think it will be awesome when you release the new graphics.

Thank you for the work you put into this game - especially how you listened to your community concerning the mods update and the bugfixing afterwards. I think most users really really appreciate that!

Let us get a little more involved and keep the hype up .

Best wishes
Robert

post is for Victor too ^^
omg,there is years i delay to post this kind of post .. thanks Rob !

yes, we saw so beautiful night & day effect 2 years ago ... and it make us in a very long awaiting and dreaming about Enduros events simulating 12 hours in 2 or 3h like in AMS2 for example....
and no more news about this dream feature ...

we are races org and last year, there was a teaser about new South City with open roads actually closed and again, we are dreaming about possibilities.

and Mods arrived, that is cool ! and Tyre physics was also in work apparently, so Night & Day and SO seems to be delayed again (yes i read the self excitement with SO in the may2021 progress report)

please, just tell us a approximative date for an update release,even partially , it will be great , the awaiting is literally a torture for an event orga with many planned events.

why not many updates ? AMS2 works like that, improvements by improvements.
ok, you are the bosses, but we are also community who bring life to LFS.. please feed us

please, give us a date .. we are turning mad

I'm just working on the tyre physics, researching, testing, becoming familiar with the new tyre model again and looking at how to make sure it behaves like real tyres.

I just need peace of mind to keep working on that. When the tyre physics is done then we will be in a state to consider how to get to a release of the new version of LFS.

That's all I know.

I guess releasing the new graphics without the new physics is out of equation at this point?
So, the good old waiting is ahead of us for unknown time.
But this time there are mods to make or drive.

I've said before but will explain again as I know not everyone would know this:

The old tyre physics does not exist in the new version of LFS. Too many things were changed - the way the tyres work, the specification of the tyre compounds, the AI drivers, various abstract things, etc. At some point I found it impossible to keep two versions of tyre physics in the one program. There is no file "TyrePhysics.cpp" or something like that. Contributions to the tyre physics are spread around many files and systems within the game code.

So it would be a lot of work to bring the old tyre physics back into the new version of LFS. It's a possible option but would be madness to do that right now. Going back into the past, and making myself suffer for no reason at all.

What seems the right thing to do is try to make the new tyre physics work properly, then all's good and we move into a new era graphically and physically. Anyway Eric still has work to do on various tracks so it's not as if we are just waiting for me. Eric is of course free to comment if he wants to but I don't want to bother him for a graphical progress report at this time. My focus is the tyre physics and that's all really.

Good .
What about splitting LFS into multiple threads : still an option currently or too much changes to be considered ?

I'd still like to do that (physics and graphics on separate threads so they can be processed simultaneously by different CPU cores) but I'll reconsider when the tyre physics seems acceptable. I wouldn't like to delay the release purely for that but it might be important for performance reasons. The new LFS does a lot more CPU work for the graphics. Although the GPU does most of the work, the CPU needs to make a lot of decisions about which objects to draw into the shadow maps. The CPU must instruct the GPU and it would be great if that graphics could use a separate CPU core so it doesn't need to share a single core with the physics.

The trouble with that (as I see it) is the separation of the cars (and other graphical elements, like skids, dust, etc) into a physical part and a graphical part. At the moment a car and its wheels have graphical and physical things all mixed in together without a clear separation. Some variables are purely physical, some purely graphical, some are shared between both. There needs to be a very good separation so the physics can continue to proceed, adjusting the car's state such as suspension, wheel rotation, body position, while the graphics system can render all the cars for one particular physics frame (or an interpolation of physics frames). It cannot simply render a car that might be half updated, part way through a physics frame. So before or after each physics frame is calculated, a 'snapshot' of each car must be stored, with enough variables to render every aspect of that car.

Because a car contains hundreds of variables, it's not a simple task to create that snapshot system, where a clearly separated graphics system reads only the snapshots, without access to the car variables that it always used in the past.

It sounds like a really interesting programming task though, but is quite a lot of work do do, as I am reminded when I look through the car and wheel structure definitions.

I kept thinking though. Remembered there may be a good "sledgehammer to crack a nut" type solution. This would be, for the snapshots, store a FULL copy of all the car variables (using direct copies of the entire car and wheel structures). These snapshots can be *written* by the physics system and *read* by the graphics system, but are created without too much brain power, just copy everything. Well, not *everything* for example you wouldn't copy the mesh from one frame to the next. So even this sledgehammer style "copy a snapshot of car" function would need some care and there is always the complication of things like, player spectates car, so car is deleted. But graphics system is still in the process of rendering the car -> crash or mysterious errors.

Some design considerations might cause quite a change. For example, the current physics frames are at 100 Hz. So to render at 60 Hz or any other frame rate, the graphical frames should be an interpolation between two physics frames. This would solve a well known problem that is particularly bad in VR. But there is an alternative solution - do physics frames at 1000 Hz instead of 100 Hz. Then store only the snapshots for the relevant physics frames and render only the nearest physics frame, not interpolated.

For example, with physics at 1000 Hz, rendering at 60 Hz graphically, we could use physics frames with gaps (in ms):
16, 17, 17, 16, 17, 17 (that represents 6 graphical frames in 0.1s).
I don't know if this slight difference between frame times would be humanly perceptible, though I'm sure it would be a lot smoother than any current version of LFS. For example, current LFS rendered at 60 Hz has gaps (in ms):
10, 20, 20, 10, 20, 20 (6 graphical frames in 0.1s).

Anyway, as I said, it's an interesting subject.

But I don't have to think about that now, it's not tyre physics.

Thank you Scawen, really, for this work. As a developer I understand the pain to rewrite che core system. But also I wonder how to test/compare it in 'real life'.. what a difficult job.

Are you planning to have more tyre compounds? Like the semi-slick for example. The new mod system welcomed many different cars but the tyres showed their limits. How strange to use a modern compound on a 1930 car. Modders tried their best to compromise, quite nicely too but always struggling, so having more compounds seems inevitable at this point.
I wonder if the new tyre physics is dependant to the tyre compounds or if you could add some after the new physics release.

Quote from Tomfuel :

please, give us a date .. we are turning mad

I totally understand the frustration, I could write the same post, but you have to stay strong!!
We waited a lot, we can wait more. The team is clearly working at full speed and I am fine just knowing that.
Silence, in this case, is good.
Don't let them "waste time" to update us, we already know what this is all about.
Updating is time consuming and it brings more questions from the people to be answered.
We will talk a LOT once it will be released.. it will be the biggest update ever!

Interesting, I didn't mean to distract Sсawen, but since we started talking about physics..
As I understand it, based on testing, it is already possible to draw some conclusions? If it is true, can i know in more detail how will this play out in practice? How specifically to change the parameters of the tire?
Will the physics of deformation change somehow? The physics of heating? Grip physics?
For example, I noticed earlier that tire heating will not affect on the grip in a positive direction as much
as in reality. Will it be fixed?

Quote from Scawen :

The new LFS does a lot more CPU work for the graphics. Although the GPU does most of the work, the CPU needs to make a lot of decisions about which objects to draw into the shadow maps. The CPU must instruct the GPU and it would be great if that graphics could use a separate CPU core so it doesn't need to share a single core with the physics.

now im a bit worried, im with laptop with intel pentium n3710 1.60ghz ( max 2.56) 4cores. ( and 2gb gpu luckily i support dx12 so at least i can run lfs after update. )

will the update affect me alot with fps / performance. since this processor is kinda lack @scawen

Quote from Scawen :

But there is an alternative solution - do physics frames at 1000 Hz instead of 100 Hz.

I think this would be the better solution (for crazy slow motion videos and stuff ).

Quote from superlame :

now im a bit worried, im with laptop with intel pentium n3710 1.60ghz ( max 2.56) 4cores. ( and 2gb gpu luckily i support dx12 so at least i can run lfs after update. )

will the update affect me alot with fps / performance. since this processor is kinda lack @scawen

Based on this https://cpu.userbenchmark.com/SpeedTest/141841/IntelR-PentiumR-CPU--N3710----160GHz it's almost one of the worst CPUs benchmarked. Only like 60 or so from last.

There are 10+ year old CPUs that are more performant.

Kepp faith Scawen, you will do magic, we are sure
Indeed splitting the thing seems a hard job ! Better to be sure to have everything under your hands before starting the journey !

Quote from Scawen :

I've said before but will explain again as I know not everyone would know this:

The old tyre physics does not exist in the new version of LFS. Too many things were changed - the way the
...
graphical progress report at this time. My focus is the tyre physics and that's all really.

As I opened this thread I feel obligated to comment now as well :

Exactly what i was talking about! Thank you so much for the update Scawen. That makes waiting a lot easier as we now know whats happening behind the scenes .

Keep up the awesome work, and as the others said, we know its not easy but you'll keep this game just as awesome as it's always been - or even more...

Thanks again
Robert

Reading the beginning of the post on physics & graphics on separate cores, I thought, "if graphics only needs to read, then there'll be no race conditions", and turned out I was wrong a lot. I guess, even snapshotting needs some care and locks, because the graphics thread may read exactly when the physics thread writes.

Quote from superlame :

now im a bit worried, im with laptop with intel pentium n3710 1.60ghz ( max 2.56) 4cores. ( and 2gb gpu luckily i support dx12 so at least i can run lfs after update. )

will the update affect me alot with fps / performance. since this processor is kinda lack @scawen

Design -> validate -> test -> optimize -> deliver.
a.0-----> a.5-------> b1----> b2--------> 1.0

If your hardware limits you, you will probably be suffering in versions b1, before the optimization. As I understood the post, the limitation right now is the design concept, on how to make it. How to manage memory reads and writes in a way that doesn't compromise the function of the game(quite the opposite).

Optimization comes after the code being validated and tested, essentially you run the game and see which functions take more than 20% of runtime.ex: divisions, If's, or cosines. optimize these, by workaround in mathematics, logic, geometry etc, and you'll get with a minimum effort the biggest results. However, optimizing should only be done after the final line of code (in this scope) being written and validated.

Nowadays, there are plenty of optimizations in terms of CPU instructions that I doubt LFS will become a resource hungry boi. But this is only speculation

Final thought, don't sweat it, If we still keep the multiple graphical sliders as of today, I am sure if you decrease the resolution, anti aliasing, LOD, anisotropic filtering, you'll end up with a light load on your machine.

Scawen, tnx very much for taking the time to write up some of your current progress on the tire physics and graphics.

Feel free to share with us some of your hard decisions, you should not be alone in this task. Many of us in the community know a thing or two about programming and physics - our suggestions may come in handy.

It's a great idea to run physics at 1000Hz and only take a snapshot whenever gfx needs to update. That would result in a much greater FFB fidelity. Also, separate threads for physics and gfx may be a very painful to do now, but a future Scawen will for sure be grateful for that decision.

Whilst we're in general-planning-for-the-future territory, can I ask for a bit of insight into collisions?

When the PPS rate was increased there was a huge difference in collisions for the better. It was much safer to rub shoulder-to-shoulder, the lag-hit type collisions were far less frequent and didn't seem any bigger when they did occur. Since the move to the new host provider it's not quite as safe to rub, and there are some enormous lag-hits on occasion.

Between that and your explanations of the LOD3 rays for modders, I'm guessing that the method for determining impact energy comes from the amount of overlap when the overlap is detected, ie, lag-explosions occur because the lag has allowed a larger overlap to happen before it is detected and dealt with.

I ask because reading the sledgehammer-to-crack-a-nut post about data access, it occurred to me that if you had access to the speed vectors of both cars at the point where you calculate the energy involved in the collision, you could cap that energy value based on the maximum overlap that could happen in a single frame given the closing speed dictated by those vectors. If I'm not misunderstanding or missing something, then no collision could ever create any more energy than a collision that involved no lag.

The problem I see with that is that the collision would still be late and might not generate enough energy to separate the vehicles, meaning another collision next frame. I can't get my head around whether or not the vector-limit thing would work in a subsequent collision or fall apart because of the effects of first one. (4D maths is really not my thing )

But, if there's no problems with vehicles not clearing each other, or if those problems are less, or 'workaroundable', then that could be the end of being pinged off the track because of a little rub coinciding with a little lag.

--

Separate thought: I'm assuming Eric won't see this, so could you ask him when you next speak if he would consider releasing the last version of the RB4 as a mod? Or if he'd be happy for someone else to yoink it from a previous LFS version and release it as a tweak mod? The new one is nice too, but the old one is like a first guitar - sometimes being better doesn't matter as much as being familiar. I miss my buddy who taught me 4WD

Quote from Scawen :

Because a car contains hundreds of variables, it's not a simple task to create that snapshot system, where a clearly separated graphics system reads only the snapshots, without access to the car variables that it always used in the past.

You mean car physics are not just car go slow, car go fast, car go left, car go right, car go straight, car go boom?

Quote from dekojester :

You mean car physics are not just car go slow, car go fast, car go left, car go right, car go straight, car go boom?

Yes,there are also: car go up,car go down,car is spinning and car is driven by Jereloco.

Don't forget cargo space... Oh wait, cargo road.

When it comes to physics, things usually take a long time...

Quote from cpn72 :

When it comes to physics, things usually take a long time...

it's usually 9.8m/s2