As I said once before in another sim comparison thread, LFS physics have the
most cohesive overall consistent feel. If I were a pure sim racer I'd probably
choose LFS as #1.

GPL's setting is flat out cool and its immersion is still impressive despite its age,
so if I were a pure sim racer I'd probably choose GPL as #2.

However, I RL race too.

rFactor, when within the confines of low slips angles and small magnitude
of mistakes driving, does indeed respond more like my RL racing than LFS
(once your brain adapts to the inferior FF of rFactor). The subtle little things
one does in RL working the tires at low slip angles seems to work better in
rFactor than LFS.

For high slip angles and bigger mistakes rFactor falls apart as compared to LFS.
LFS is the better physics whole.

However, as I said, I race RL and I use sims to practice. So I actually spend
much more time in rFactor (mainly rF3, F-Sum, and FIS) than LFS. I have more
'fun' in LFS. I get better practice in rFactor.

The ultimate sim still seems so far off. GPL, rFactor, LFS, NKP, DR, are all still
so incomplete in physics. I have driven them all, and honestly I think LFS is the
closest to being complete, but where it is short is where it hurts my practice the
most.

Quote from jtw62074 :

Initial turn in bite, if you're thinking of the same thing I am from the 'behind the wheel' perspective, is likely the initial cornering stiffness, unless you're talking about steering to a large slip angle and then activating your butt-meter. The higher that initial cornering stiffness is the more turn in bite you'll feel. Granted, two tires could still peak at the same slip angle, but the shapes of the curves before that could still be quite different. This is probably what you're feeling as the difference between the two.

You're correct, I am talking about immediate bite on smooth initial turn-in. I don't
tend to yank a car/kart around.

Actually, modern kart tires, Mojos (a lousy RMC spec tire) aside, have a very soft
section between the sidewall itself and the tread section. Also, the sidewalls are
flexible so that their flex does much of the work instead of depending mostly on
slip/scrub. Most of the guys here with recent kart experience can back that up since
karters pretty much all mount and unmount our own tires by hand, so they are
pretty intimate with them.

A kart tire peak and a formula tire peak are at very similar slip angles, and their
falloffs follow very similar curves. They are basicly the same in design principles,
and differ mostly in just form factor.

That bite I'm talking about may very well have something to do with tire flex,
as that stiff tire I mentioned, the Mojo D1, has much less turn in bite. I noticed the
same with endurance tires, which are also very stiff. I won't conjecture on why,
although I have ideas, but it seems there may be a link between flexible carcass
and turn-in bite. The Yokohama GP1, which has a ton of turn-in bite, is a very
gushy bouncy tire (it also has a large rollout for a kart tire), so much so that it
affects driving technique.

Most of this I got talking to Yokohama kart tires developers 2 years ago at the
Black Rock Summer Shootout, where they were trying to launch their GP1 kart
tire (and at which they had major quality control problems, which brought up a
lot of technical tire talk).

At Willow Springs I watched the front tires themselves through the highly loaded
sweepers. It is almost scary how much they deform laterally under load; I actually
thought I had a defective tire at first when I saw that (in this case it was Bridgestone
YHCs).

So maybe what I observed is a shortcoming in the LFS tire model that will indeed
get fixed.

Last edited by orangutan, Wed, 8 Nov 2006 23:30.

I have been doing a little more specific and focused back to back testing of
the LFS FO8 vs. our rFactor mod car (f-sum-gp, a 500hp open wheel car...so close
to the FO8) vs. a test day on a Rotax Max with MG Yellow tires (a really well designed
modern slick).

I set force feedback very low so as to take away the impression that FF imposes on
the actual physics modeling. rFactor's stock FF, and even when heavily adjusted,
is only good for more cerebral informational feedback (in which case it is better
than LFS), and not so much so for realistic feel (in which case LFS is better). I
am currently focusing on actual handling comparison, not FF, so I turned it down.

Also, note when I say 'LFS does this or that' below I mean LFS FO8 with a setup
I like. I know it is possible there are other cars or setups that invalidate my
observations...but I'm doing what I can. Same goes for rFactor references.
Still, my feel observations certainly seem simulation systemic to me, so I think they
have weight.

Since I am using the MG yellow test as the realistic baseline, which is a totally
different vehicle than 500hp open wheel cars, I have to be careful what I am
comparing. So I decided to focus very narrowly on a couple of data points that
seemed different in earlier tests and would hopefully be as chassis/motor
independent as possible. So I pick very initial turn-in, before significant weight
transfer, and quasi-steady-state drift with the car set...again with little dynamic
weight transfer.

As probably expected, in heavy drift, LFS was far more natural and like the real
vehicle drift. Corrections basically worked as expected, both wheel and throttle.
rFactor was not as bad as I was expecting, but still has something of an unnatural
feel, especially with respect to throttle corrections. They both spun easier than
the kart, but that is to be expected since the kart has a live axle and the cars
have more power/weight.

On initial turn-in, on fresh tires, with that first little bite, rFactor was better. Actually,
on this behavior rFactor is rather impressive. LFS was much 'softer' on turn in
resulting in a more gradual cause and effect than I got on real life new tires.
LFS does not really even have that little 'bite' that the real tires have.
I wore the real life tires down pretty far, which LFS matches really well. My worn
real tires had that same soft turn-in, at least until I wore them to the point of
just pushing like a truck (by which time my neck had nothing left anyway; MG
Yellows last really long for their grip level). As rFactor's tires wear out, the
turn-in continues to match my reality test very nicely, they give up that bite in a
similar way.

These are two very narrow little tests, but it does show, for a particular driver's (me)
expectations with respect to reality, neither sim is completely satisfactory. Doing
this same sort of testing through more of the envelope would require using a
matching vehicle in real life, as weight transfer, power, etc become more integral.

If I do another Formula Renault test I'll try to back to back it with rTrainer and FOX.
As I recall that formula car was much like a kart but with less G loading than the
kart (for those non-karters out there, you'd be shocked how many Gs real racing
karts pull) but mildly variable grip with speed (aero).

Last edited by orangutan, Wed, 8 Nov 2006 19:05.

Quote from Dennis93 :

i Dont like ur opinion Bout karting ..
Really Those things are fast .. and i drove a Rotax .. its pretty dead if u compare it to a ICA JUNIOR ..
IMO

I don't quite understand what you don't like about my opinion.
That is what I was saying...karting is high performance. I said
the name 'kart' was bad becuase it implies 'toy' or 'slow' to
most people who do not know better. It is the name
I said is poor, not the sport. The sport is the raw essence of racing.

I have driven ICA, TaG, ICC, 4 stroke 250cc kart, and Rotax Max,
and yes the ICA (and maybe even JICA) kicks the Rotax off the
bottom, but the ICA can go maybe 60 minutes before a rebuild
where the Rotax can go 50 hours.

Quote from z3r0c00l :

... A lot of the time it's 4am in the morning and I'm hurtling about backroads...

... I would love to consider myself a race driver, ...

... I've got a few grand sitting on my desk right now, awaiting the perfect car to come up...

Get off the public streets before you kill someone (I used to backroad sprint
too back when I was 17, and in retrospect it was one of the more stupid things
I've done).

Karting is the most performance you'll get until you get to really high end cars (GP2,
Nippon, Atlantics, etc). Even F1 drivers usually practice with karts, not lower car
formulas (except when the FIA/CIK prevents them like Speed and Liuzzi in the SuperNats).

With that money I think it would be best to get a used Rotax kart and 'Live' for speed
off the public roads and on purpose built tracks.

'Kart' is a bad name for what they have become. They really are just small open
wheel formula cars now, where you treat axle flex as your replacement for a diff.
Rotax Max is probably the best kart formula for budget performance due to the
sealed motor (although in the U.S. there is also Spec/Stock Moto as an economical
choice; there may be alternatives in your country as well).

Last edited by orangutan, Tue, 7 Nov 2006 17:09.

Quote from J.B. :

Interesting. I'm trying get a bit of an understanding of Backward Euler:



So ds1 is the time derivative of s(t) at t=1 (to be multiplied by the time step I assume). But what is s(t) in a racing sim? I guess it can't really be a function since the external inputs to the simulation are always changing. Come to think of it, if this function were known there wouldn't be much point for any numerical integration would there? Is it an interpolated function calculated from known, past values?

Yeah, you're getting it, and yes I sort of munged (s'(t=1) * dt) into that ds1.

s'() is just the equations of motion. F=ma stuff. (x' = v, v' = a)

BTW, my simplified notation will break down if we push on it too hard...call it
quasi-notation.

And your line of thought is leading the right way. For backwards euler we solve
the system of linear equations we derive (using a Taylor expansion) from the
system of non-linear equations we get from asking
'what is s(1) such that s(1) - s(0) - s'(1) * dt = 0'

How do we find that? Well, we can guess, plug the numbers in and see if we are
close. If we miss, we can take that miss information (the residual), and somehow
use that to guess again. And again.

In effect we simply iterate educated guesses until we get the answer within
tolerance. These guesses are often based on following characteristic
eigenvectors (just think orthogonal deltas of the state vector to try) of the system,
which is to say a conjugate gradient solver. This iterating is why semi-implicit is
more expensive than explicit. (We could not iterate, using gaussian elimination,
since we linearized the problem, which is in principle more deterministic, but in
practice CG is faster for these sparse systems).

Since I've gone this far, the linear system is an approximation of the non-linear
system. We could do an outer iteration to solve that system, using linear system
solves as non-linear guesses. Way more expensive, but that is what a full
implicit solver (like Newton's method) would do.

That has to be the absolute shortest description of implicit integration I've ever
seen, so I don't know if it is understandable at all.

Peptis, I agree implicit integration will not solve the lag induced collision problems,
but it would make run of the mill stiff (in the mathmatical sense) situtations more
stable. There are lots of factors in deciding on an integrator. My main point is that
IF a moddable simulator chooses to do so, it would be useful to know as a modder
with respect to directions of exploration with mod parameters or extensions.

Last edited by orangutan, Thu, 2 Nov 2006 01:34.

Quote from J.B. :

Nice posts orangutan.

Two questions: what do you mean exactly by the term "pre-spin state"? Isn't it more or less the same as oversteer?

And do you know if any modern PC sims are using integration methods other than Euler. My impression has been that todays CPU's haven't made this possible yet or that some methods were just not worth it.

Here are two posts on the subject by the devs of Rigs of Rods and Racing Legends:
http://www.lfsforum.net/showthread.php?p=149882#post149882
http://www.lfsforum.net/showthread.php?p=149954#post149954

Similar to oversteer using the definition of oversteer as the rear tires having a
greater slip angle than the fronts. However, this is different than the common
understanding of oversteer as 'loose' or 'not enough rear grip', since these imply
more of a setup condition as oppossed to a particular dynamic state. In practice,
I myself use the less formal later definition instead of the formal definition...hence
I differentiate by using a term like 'pre-spin'. In the case of rfactor, I therefore meant
'a high degree of formal-definition oversteer'.

Yes, I know of a few instances where semi-implicit integration is making its way into
games, but I know of no top shelf racing games. For example, I know some
secondary physics in the PS2 game Darkwatch are done this way (I know one of
the coders). Havok supports such integration, so I'm sure other games do it as well.
Any game that is using Qualoth cloth is using semi-implicit. I have an articulated
tree sitting in front of me right now simulating at about 100 fps with 737 branch
segments using backward euler with a biconjugate gradient solver (slower than
conjugate gradient but can handle a non-symetric system) on an opteron
275 (at work).

I agree with the position in those threads you posted that Euler is likely more
appropriate than RK4 for this application. Also, the difference in mod parameters
would likely be minimal between Euler and RK4. Backwards Euler changes that,
which makes is more relevent to know if it is being used. The question to me is
then: if/when will backwards Euler makes its way onto the real-time racing table?

Last edited by orangutan, Wed, 1 Nov 2006 21:53.

Quote from axus :

Orangutan, am I right to understand semi-impicit integration as a method of working in time steps, but once a collision is detected by one body sinking into the other, it tries to "roll back" to the moment of the crash and correct itself? If not, surely this is possible to some extent? With the physics running at 100Hz, and cars travelling at some 60m/s, that's a movement of 0.6m per time step, a pretty small distance. You could probably do a good estimation of when the colision actually happened from there, basically reversing the integration with a more accurate, implicit expression between the previous time step and the current one, and let the collision handling model handle the rest, as you described.

On the other hand, when racing online, inaccuracies can go as far as 30m in heavy lag situations at high speeds. Granted, at those speeds, the relative speed between the two cars will be much smaller at any case in most collisions, but is it not possible to again obtain an implicit expression describing both cars' motion reasonably well for a period of half a second close to the time of the collision (each PC does one for its own car), swap this over the network and only then calculate the collision? Atleast for collisions that appear major? Sure, you'd wait half a second between collision and effect, but atleast you didn't lose the race because of a collision that shouldn't have happened in the first place. I can't think of a situation where this would be more frustrating/problematic than the current method.

Hope I made some sense.

No, actually explicit/implicit/semi-implicit really refers to the the differential model
equation being solved per timestep, no matter what the adaptive stepping approach
taken.

Given s0 as the initial state vector (usually the position and velocity degrees of
freedom) and find s1 as the new state vector:
explicit Euler: s1 = s0 + ds0
implicit (backwards) Euler: s1 = s0 + ds1 (s1 is a function of its own derivative, hence a system solve)

Rolling back is a part of adaptive time stepping, whose steps can be solved using
any step integration method (well, almost...it gets trickier with step solvers that need
history, especially if they leverage fix step lengths).

An adaptive time stepper is problematic for real time. I use it for my non real time
collision detection and response, but it is inherently non deterministic in CPU time.
This means the game could easily get into situations where it would stutter. Plus
it is hard to imagine a clean way to step back in time when the players are
already reacting and interacting past the critical collision time...because note that
lag induced problems can put the critical collision time farther back than one
time step.

It would seem to me that a more robust way to resolve lag induced over
interpenetration is to either do what rfactor does (turn those collisions off), or to
limit the effective penetration depth; which is to say that the response on a given
time step will never be more than as if the collision is at some reasonable depth X.
This would effectively spread the resolution of an over deep collision out over time.

Last edited by orangutan, Wed, 1 Nov 2006 20:38.

As has been said, collision detection and response are a different subsystem
from the articulated rigid body dynamics. However, note that there is a
semi-continuous collision happening with the tires and the ground most of the time,
which itself is usually a sort of third subsystem due to detailed tire models.

Underlying a lot of this is whether or not to time integrate explicitly, implicitly, or
semi-implicitly. To put it very simply, explicit costs less per timestep, can be pretty
high order accurate for cheap (RK4, etc), but simulation error injects energy into the
system. Think of a simple planetary orbit simulation. Explicitly integrated, the orbit
will expand over time. With too big of a timestep it will shoot away, just like some
LFS and GPL collisions. This can be patched over with damping (likely non-linear),
velocity caps, whatever.

True implicit integration is too CPU expensive for real time simulation. Semi-implicit
integration (basicly one iteration of implicit, linearizing with a Taylor expansion) is now
becoming real time viable on modern hardware. The bottom line is that
semi-implicit integration is more stable and its error bleeds energy from the system.
The orbit of the planet would decay. Extreme collisions could deaden (depending
on the collision response model). The main problem with semi-implicit is that
it requires correct Jacobians (think first derivatives) to setup a sparse system, and it
needs a sparse linear system solver (often preconditioned conjugate gradient).
Although conceptually simple, these things kinda work even when they are wrong,
so they can be tricky to get exactly right. Also, there is probably no way the AI
would get the same integration. Semi-implicit is still probably too CPU expensive
for that.

Anybody left? Why does this matter? Because this tidbit is fundamental in how
the dynamics, including both normal driving and collisions, inherently look and
feel when in the realm where numerical simulation error is not negligible, such as
real time gaming. I'd really like to know, especially in a moddable system like
rFactor or S3, what choices were made underneath for time integration. It would
affect directions one may investigate in things like mod tire parameters.

I write physical simulations myself for a CGI movie company (like cloth,
feathers, rigid bodies, fluids, etc). So to put a point on this, when artists try to
get silk out of my cloth solver, they cannot just put in silk material parameters...they
have to be mildly tweaked one way or another to get just the right look based on
whether they are using Euler (explicit) or BDF2 (semi-implicit) to solve.

The other reason I bring any of this up is to quash all this 'exactly right' so 'live
with it' talk. It is not exactly right. Only real atoms and all their emergent structures
do it exactly right. Tradeoffs are made. LFS makes some one way. rFactor makes
some another way. They also both make a lot of the same tradeoffs, which in the
big picture is why I think they are more similar than different. So they both
make compromises restricted by the resources available.

Last edited by orangutan, Wed, 1 Nov 2006 17:12.

Quote from Viper93 :

As for RFactor Vs. LFS how could you even think of compairing them?

Because some of us may have to choose between one or the other. It could be
money, time, focus, whatever. In my case it is a choice for our league...we cannot
expect members to buy multiple sims and get familiar with them all.

So a choice sometimes has to be made.

As for our choice, we are undecided. We (organizing members) have been working
up a mod in rfactor that is just some tweaks to suit our league, but we have also
been working with LFS.

Our opinion so far...opinion. Again, opinion:

The funny thing is that we have the opposite opinion about some things than the
prevailing opinion here, for better or worse. For example, I think LFS sounds are
better than rFactor. Certainly they sound synthetic, but they also sound alive and
informative (although I have raced RL as well, and engines in RL are not always
so nicely informative). LFS wins sound.

LFS FF is unquestionably more immediate and real, but in a funny way is floatier
and less informative. The hackery in rFactor's FF does bridge the information gap
we have from not being in a real car. I'd have to call FF a draw, in spite of LFS's
clearly superior FF base. That extra rFactor information is worth something, and I
don;t mean the canned bumps, which I turn off. I means the hacks to convey loss
of front end, etc. Not strictly realistic, but in RL we get the information in other
ways...so overloading the FF with more info can be justified (same goes for
sound...which is why LFS wins sound).

The physics is misleading. Drive one or two hours of both and you'll likely
agree that LFS has better physics. However, drive two weeks of both, and the
tables even out. Drive two months of both, and they both have irritating breaks
from reality. They clearly are both based on multibody time integrated dynamic
simulations. rFactor is NOT table based at its core, although it seems to have more
layers of something going on above this core...for better or worse. LFS has a
cleaner rawer feel, like GPL, and seems truer to its own
model, and breaks down only when the core model itself breaks down, which only
happens in subtle ways. rFactor, like with FF, seems to have more hackery atop of
its model, but often for the better. Any simulation model is just that, a model, a
simplification, and they all break down somehow somewhere. LFS gently just
seems to follow its math where ever it leads, always natural within its own reality.
rFactor on the other hand seems to explicitly make an effort to feel right, as in more
calibrated to reality in feel, within its sweet spot...which is normal driving within low
mistake slip angles. Within this window I have to say rfactor actually feels better.
However, when rfactor breaks downs it is jarring and unnatural, unlike LFS. Worst
case is pre-spin slip angles and angular momentum, where rFactor gets downright
whacky.

To summarize physics, if you want a full performance envelope that feels self
consistent and natural within its own approximation at all times, LFS wins. If you
want more RL realistic feel within nominal conditions, and can deal with odd
behavior and strange transitions in extreme conditions (like pre-spin), rFactor wins.
I think this is why the RL drivers in our league prefer rfactor physics (when you
don't make big mistakes, rfactor feels more real, and the rfactor junk you get when
you screw up serves you right ) while both the hardcore sim racers
and console migrants in our league prefer LFS physics (without RL experience there
is no 'real', and LFS is a tighter cleaner feel throughout the envelope).

Despite the two big preceding paragraphs on physics, both LFS and rFactor have
what I'd call state-of-the-art consumer grade physics. Hopefully, rF2, S3, DR, etc
will move the state-of-the-art itself forward.

Graphics engine, rFactor wins, no question. Pallette-wise, within the default content,
LFS makes some better choices...but rFactor has the better graphics.

Flexibity, results exposure, and all the other stuff that comes with modability, goes
to rFactor. What LFS does, it does right within it decisions, but it just doesn't do this
part (yet).

UI and setup, for our league, actually is better served by LFS. It is cleaner, tighter,
and just the right amount of setup parameters. rFactor can be overwhelming in
this respect to the console migrant and RL contingent (RL racers seem to have
simpler cars they tune themselves or have engineers for more complex cars).
rFactor's suspension can make even RL racers feel like they are doing more work
and less play. LFS also pops between screen much quicker and the whole
UI experience is quicker, cleaner, faster, and less frustrating. LFS wins UI and
garage, despite its seemingly arcadey approach to the matter.

AI. Bleck. They both suck to an embarassing level. This is like trying to decide
which sewage smells better. I'll actually give it to LFS for the humor vote. It is
still a riot watching untrained AI spin about just like human newbies.

So our league is undecided, and may come down to one last issue. Aids. Our
league trys to accomodate consolers, RLers, and hardcore simmers...which means
consolers need/want aids to play along with non-aid hardcores. RLers tend to
go in between, optimizing for for RL feel of their particular RL car. rFactor wins
in aids support. Still, lower powered cars don't need aids even for consolers, so
the decision is not made.