Live for Speed now has a much needed update

[Alex Franchini]

One of the underdog simulators, Live for Speed, has finally received an update (version 0.6J) after a long period of silence.

Live for Speed was originally published in 2003 and developed by a three-strong team to become one of the most respected simulators around. While it's been overshadowed by newer, flashier games, LFS still has a loyal and dedicated following.

Patch 6J brings performance improvements in order to reduce the load on CPU and GPU. The game now also has a more accurate frame limiter, and Oculus VR users can enter and exit 3D-mode without leaving the game.

Changelog:

• Static vertex buffers reorganised to reduce DirectX instructions.
• Frames buffered (default 1) to allow next frame to start rendering.
• More efficient car distance sorting system for sound and graphics.
• Dynamic vertex buffers now set to use hardware vertex processing.
• Better frame rate in places where many objects may be visible.
• Sky texture is now drawn in mirrors.
• Layout editor object selection buttons are sorted by distance.
• Z-buffer depth setting can now be changed without restarting LFS.
• Mirror now uses 24 bit Z buffer if Z buffer setting is more than 16.
• Frame rate limitation system is now accurate and has better values.
• New frame info display shows sleep / physics updates / gpu waiting.
• Now using an event query instead of a lock for input lag prevention.
• Minimum sleep setting changed to "Sleep every frame" (yes / no).
• Now using Direct3D 9Ex if available (Windows Vista and later).
• Reduced glitch when autocross objects are optimised (e.g. on load).
• Reduced min / max values for "Sound lag" setting - default now 0.08
• New Audio Option "Sound when window is inactive" (off / on).
• Added a 3D level slider option to adjust monitor-based 3D views.
• Reduced CPU / GPU usage by sharing scene preparation for both eyes.
• Now using Oculus SDK version 0.6.0.1 which includes timewarp.
• You can now enter and leave Rift mode without restarting LFS.
• Smooth display (if you do not use SLI or force vertical sync).
• Monitor window view options : blank / one eye / two eyes.
• For users who cannot use the Oculus 0.6 runtime, you can still use the 0.5 run-time. Simply rename the ORDIRECT.dll to some other name, and LFS will then use LFSORDLL.dll instead (extended mode only).
• Some buildings at Westhill track were drawn using a slow method.
• Mouse clipped to window (CTRL+C) now works properly with ALT+TAB.
• Using mouse wheel to change gear did not work properly at high fps.
• Layout editor object selection buttons used interface button slots.
• Crash changing texture resolution with two or more objects selected.
• Anisotropic filtering did not work on car textures (including skin).

 

[Richard Eriksson]

@Richard Eriksson
Actually, I think their driveline model is pretty neat already... To the point of letting use it as a training aid for the new folks who are about to get acquainted with driving a manual. The only other tittle that required a bit of skill while starting from a standstill was netKar Pro. And I'm not entirely sure the latter didn't have the hideous autobraking feature to prevent you from rolling downhill with the clutch disengaged.
They could, however, benefit from having the driveshaft flex (as in R3E) AND from the rev-matching clutch-less shifting for the appropriate gearboxes (partial support in R3E, full-on in Project CARS).

As for the "subpatch" tire model... Maybe you meant a brush-based one? I'm pretty sure that IS what LFS uses to this point. As do rFactor 2 and Project CARS... This type of modelling, however, seem to calculate interactions of a set of points comprising the tire's mesh with the road surface.

I never said their systems wasnt good, only that they could be made better by taking a step back and starting over with the lessons learned over the years. Of course it's good, it's been around long enough to prove that

As for the tyres, to explain since English is not my native tongue, but with subpatch i am referring to splitting the tyre mesh into separate smaller contact patches and individually calculate the slip and adherence based on the vars unique for each subdivision, then normalizing the results into a combined vector used for actual transformations.

My understanding of brushes is that it instead divides into segments, not flat patches. The bonus of it would be tyre flex and deformations at a higher computational cost.

But yeah, the principle of my post is still this: the software is getting old and like all software getting old, it can benefit from a larger rewrite taking into account new advances... One of those being increased computation power and support for multiple hw threads also on consumer machines.

Disclaimer: i have never worked with what i think you mean by "brush based" modeling only subdivided flat patches so my understanding and interpretation is based on that...

 

[Shaun Clarke]

This is such a shame, as I was an avid LFS racer, follower, promoter and had been for years, but it is out of date now, not even DX10 I think, if I remember, S3 was promised....moons ago ( I still have £10 credit that I paid in to years ago ready for S3) and that was before I got re-married....(re-married 8yrs ago.)

No Scirocco, no Rockingham, and just concentration on OR (which a lot of people don't have anyway)

 

[liquido]

Long time ago LFS was the reason for me to change my Playstation2 for PC machine to play racing games.

Today I read that updates and I feel embarrassment.

 

[TzZyO]

I never said their systems wasnt good, only that they could be made better by taking a step back and starting over with the lessons learned over the years. Of course it's good, it's been around long enough to prove that

As for the tyres, to explain since English is not my native tongue, but with subpatch i am referring to splitting the tyre mesh into separate smaller contact patches and individually calculate the slip and adherence based on the vars unique for each subdivision, then normalizing the results into a combined vector used for actual transformations.

My understanding of brushes is that it instead divides into segments, not flat patches. The bonus of it would be tyre flex and deformations at a higher computational cost.

But yeah, the principle of my post is still this: the software is getting old and like all software getting old, it can benefit from a larger rewrite taking into account new advances... One of those being increased computation power and support for multiple hw threads also on consumer machines.

Disclaimer: i have never worked with what i think you mean by "brush based" modeling only subdivided flat patches so my understanding and interpretation is based on that...

Who knows... Maybe Scawen is already working on a scratch made engine as we speak. At least it's hard to believe it takes him literally years to bring some minor updates to the title. So, maybe they are just some sort of a post-release support for S2. At least it's something I want to believe personally It would be a shame for Scawen to just settle down with this "beta" and bringing the framerates into the thousands territory.

Ok, separate smaller patches it is then. Are they isotropic grip- and slippage-wise? If they are, then how can that provide a higher fidelity than the "contact point on a stick" model? And if they aren't, wouldn't that require yet another subdivision level to ensure any anisotropy?
As far as I'm concerned, the setae in a brush model do interact with all the adjacent ones (making it more of a flexible mesh rather than a brush), and tire flex must be very important. We can actually see the damn thing happening on cars next to us, so it's not a micrometric level or anything like that...
And if Scawen managed to achieve tire flex almost 15 years ago, with our current hardware it shouldn't be a problem at all. As ISI more or less demonstrated with rF2

I'm personally with you here on the point that LFS could use a more technologically advanced engine. The question remains, how long will it take Scawen to come up with one? Won't it get equally outdated once he's finished?
If he had a team of at least a dozen of programmers, that wouldn't be an issue at all. Apart from the arising need for a dozen of the visuals supplying guys as well, since the complexity of any 3D stuff would simply skyrocket... But there is just one programmer and one artist. Can they realistically pull this off?

The subdivision patches based model is pretty unheard of, as far as I know, so if you'd care to elaborate on it, that would help a lot. The "brushes", on the other hand, are used in LFS, rF2 and Project CARS so far, making it quite a popular choice. The rumour has it iR and AC are going to receive related models sooner or later as well...

By the way, even though asking the question "why don't you do it yourself then?" seems to be impolite and immature, still... it looks like you have all the assets to start a project like this. The most valuable one being the enthusiasm plus the experience. It's not like the market is exactly overloaded with good car sims, so... Why not?

 

[Richard Eriksson]

Who knows... Maybe Scawen is already working on a scratch made engine as we speak. At least it's hard to believe it takes him literally years to bring some minor updates to the title. So, maybe they are just some sort of a post-release support for S2. At least it's something I want to believe personally It would be a shame for Scawen to just settle down with this "beta" and bringing the framerates into the thousands territory.

Ok, separate smaller patches it is then. Are they isotropic grip- and slippage-wise? If they are, then how can that provide a higher fidelity than the "contact point on a stick" model? And if they aren't, wouldn't that require yet another subdivision level to ensure any anisotropy?
As far as I'm concerned, the setae in a brush model do interact with all the adjacent ones (making it more of a flexible mesh rather than a brush), and tire flex must be very important. We can actually see the damn thing happening on cars next to us, so it's not a micrometric level or anything like that...
And if Scawen managed to achieve tire flex almost 15 years ago, with our current hardware it shouldn't be a problem at all. As ISI more or less demonstrated with rF2

I'm personally with you here on the point that LFS could use a more technologically advanced engine. The question remains, how long will it take Scawen to come up with one? Won't it get equally outdated once he's finished?
If he had a team of at least a dozen of programmers, that wouldn't be an issue at all. Apart from the arising need for a dozen of the visuals supplying guys as well, since the complexity of any 3D stuff would simply skyrocket... But there is just one programmer and one artist. Can they realistically pull this off?

The subdivision patches based model is pretty unheard of, as far as I know, so if you'd care to elaborate on it, that would help a lot. The "brushes", on the other hand, are used in LFS, rF2 and Project CARS so far, making it quite a popular choice. The rumour has it iR and AC are going to receive related models sooner or later as well...

By the way, even though asking the question "why don't you do it yourself then?" seems to be impolite and immature, still... it looks like you have all the assets to start a project like this. The most valuable one being the enthusiasm plus the experience. It's not like the market is exactly overloaded with good car sims, so... Why not?

For subdivision strategy, i will attempt to explain. Note that this was used by me in the past for projects where maximum fidelity simulation was not needed. The benefit is speed over complexity. So it is very fast compared to a full brush-model (or segmentation).

What you do is you take the area of the contact patch, and split it in subdivisions. Then you calculate the slip angles relative to the axle vector for each subdivide according to a formula with preentered constants. Then total slip and grip is based on normalizing these subvalues into a union vlue relative to axle velocity.

As you see, there is no concern for tyre flex in this method, neither deformations of the actual carcass. It is merely a way of getting to a model where you can express "the tyre is partially on the kerb, thus has x amout of reduced total grip" or "the load (given by a constant) on the outer subdivisions are high but the lower in the center, thus giving x of total slip (normalizing inner subsurfaces grip, with outer lack thereof)". If you understand?

So a full brush based model is better, but it is more costly. With subdivision, you have a model that is faster and can thus run it at a higher frequency.

Note also that my project was not based on cars, it was in fact based on flight simulation, so the tyre modeling was used for simulating landing wheels. Thus focus was more on aero simulation than on tyre deformation

However just thinking about it, i can imagine a combination, where you have a brush based model to account for deformations to the carcass and shearing, running at a lower sample rate coupled with faster flat patch subdivisions for general grip/slip calculations using constants (partially fetched from previous brush tests).

As for writing my own car simulation... Well it would be interesting, but the problem is not willpower or experience/skill... It's time. Like many others i work a lot. And i mean A LOT. On top of that i have a wife and a kid. So yeah... Not much playtime for such projects.

I do however nourish an idea of a smaller scale project where a top down 2D perspective could be coupled with a semi-real physics model to create a realistic simulation version of Super Sprint.

Unfortunately my programming life nowadays is very much about business systems and mainframe big data and very little about simulating cool stuff.

 

[Spinelli]

In certain vehicle behavior scenarios, Live For Speed still absolutely obliterates every sim out there (with Netkar Pro coming 2nd). Not overall, but in certain scenarios.

It's quite sad how all these new sims with there apparently "fancy" physics engines still do a lot of retarded and completely unnatural & "digital" things when you reach and/or push over the limits compared to Live for Speed (and also Netkar Pro to a certain extent).

 

[TzZyO]

For subdivision strategy, i will attempt to explain. Note that this was used by me in the past for projects where maximum fidelity simulation was not needed. The benefit is speed over complexity. So it is very fast compared to a full brush-model (or segmentation).

What you do is you take the area of the contact patch, and split it in subdivisions. Then you calculate the slip angles relative to the axle vector for each subdivide according to a formula with preentered constants. Then total slip and grip is based on normalizing these subvalues into a union vlue relative to axle velocity.

As you see, there is no concern for tyre flex in this method, neither deformations of the actual carcass. It is merely a way of getting to a model where you can express "the tyre is partially on the kerb, thus has x amout of reduced total grip" or "the load (given by a constant) on the outer subdivisions are high but the lower in the center, thus giving x of total slip (normalizing inner subsurfaces grip, with outer lack thereof)". If you understand?

So a full brush based model is better, but it is more costly. With subdivision, you have a model that is faster and can thus run it at a higher frequency.

Note also that my project was not based on cars, it was in fact based on flight simulation, so the tyre modeling was used for simulating landing wheels. Thus focus was more on aero simulation than on tyre deformation

However just thinking about it, i can imagine a combination, where you have a brush based model to account for deformations to the carcass and shearing, running at a lower sample rate coupled with faster flat patch subdivisions for general grip/slip calculations using constants (partially fetched from previous brush tests).

As for writing my own car simulation... Well it would be interesting, but the problem is not willpower or experience/skill... It's time. Like many others i work a lot. And i mean A LOT. On top of that i have a wife and a kid. So yeah... Not much playtime for such projects.

I do however nourish an idea of a smaller scale project where a top down 2D perspective could be coupled with a semi-real physics model to create a realistic simulation version of Super Sprint.

Unfortunately my programming life nowadays is very much about business systems and mainframe big data and very little about simulating cool stuff.

Ok, so basically it's a "Pacejka Magic Formula" variety interpolated over a set of points comprising a rigid contact patch? I assume the torque resulting from any difference in friction between the points is not taken into account?
Honestly, I can't see a reason to use a downrated physics model this day and age while even the S1, as far as I can remember, used brushes. Even rF2 employing its overcomplicated brush tire model runs more than decently on a modern hardware, so what's the point for Scawen to take a step back instead of forward? His brush model is exceptionally optimized (to say the least), and low framerates doesn't appear to be an issue at all. In fact, there seem to be enough room for improvement through more complexity, not the other way around...

As for landing gear modelling, shouldn't be tires carcass deformation even more of an issue for a plane? With tens of tons acting on a wheel and all the dynamic loadings, one would expect the deformations to make some serious impact on the overall aircraft's behaviour.
Even though aerodynamics is crucial for a flight simulation, modelling the process of bringing the bird back to the ground in one piece is even more important. Especially for a serious training suite...

Well, the family and the main job can eat up all the free time for sure. It also quite likely could be what happened to Scawen after all... Maybe he just doesn't have any free time anymore.

Anyhow, the amount of people eager to pay some serious bucks for a good cars simulation is to be reckoned with these days. And if one happens to be enthusiastic enough about it themselves, they should really consider carving out some time for helping these people realizing this dream.

 

[Richard Eriksson]

@TzZyO , yes it is basically a magic Formula based approach, but applying it recursively along subsectors of the patch. So yeah, not really an option on it's own in this day and age. Could however be combined with a brush model for rough calculations at a very high rate, then using brushes at a regular rate.

As for carcass and pressure sim in the flight sim i did, i faked it Bear in mind that this was back in 2001 or so and despite it being military workstations running it they wouldnt really cope. So we faked some parts to maintain simulation rate for the aero. Would have loved to redo that using new tech actually... A sideeffect of a different cheat we did was that if you had your plane running at a very low speed on the ground, wind could flip it upside down A side effect of the drag formulas... Luckily noone ever noticed despite 10 000 plus hours of use time

What i personally would love for racing sims in the future however is two things:

Tyre carcass deformation on mesh level (chunks of rubber breaking loose from the carcass itself altering the contact patch area and pressures).

Full dynamic body and chassis damage. Today we have simulated mechanical damage (still very digital). In racing it is important irl if a fender is dragning and how it drags, as well as if you loose bodywork and where. Also the chassis could get bent and so on.

I do not buy into the ISI saying of "this is RACING sim, we dont do crashes" as crashing and aftermath (debris, car deformation) is part of racing... Debris in particular.

 

[Peter Klawitter]

anyone racing on LFS? any RD members/ users who are actively on LFS?