Quote from Matrixi :

Tyre physics won't help much when even basic things like the gravity is all wrong.

Gravity is the simplest thing you can model in a physical simulation. Anything that looks like bad gravity modeling has almost certainly nothing to do with gravity modeling. Unless it is done on purpose which no sim developer in their right mind would do..

Quote from PMD9409 :

I think all that power to the rear wheels could be even more of a headache.

I meant the physics model
Oh course, it's high time they made it capable of 4wd, but a lot of things regarding physics development happen very slowly at iR. (Not that I'm really faulting them, I know perfectly well how time consuming something seemingly trivial could be to implement. This is mostly due to the hardship of matching the new feature with your existing codebase if you didn't take that feature into consideration previously.)

Quote from anttt69 :

I think hyper is right. They need to go for the 4wd version or a toned down 2wd RUF. 700bhp will be to much of a handful.

I have a feeling that the physics model might not be ready for 4wd yet.

Quote from Juzaa :

This is wrong, it actually is just that simple

No. You forget the Lady
Also, 5th gear has a few actual racing drivers, while Top Gear has.. a fat man, a small man and a slow man.
..Apart from these, you are correct of course.

Quote from jtw62074 :

I suspect his meaning of "played with" meant something a bit more than that

Hm, you're probably right
Although he could've written "experimented with" for disambiguation

Quote from Bob Smith :

I've not played with a multi-body engine first hand, however.

So you never played NetKar Pro or rFactor?

Quote from JeffR :

I doubt that any equation and/or table based approach is going to be able to simulate how a wide variety of cars and tires behave at the limits of traction. No matter how unpleasant it sounds, it seems that the equivalent of some canned effect is going to be needed to prevent cars from exhibiting unrealistic behavior when at the limits.

Taking a cue from the radio control model world, more and more computerized assists are being placed into model aircraft. Helicopters have had heading hold (these maintain orientation despite any side loads) gyros for yaw control for decades and more recently, pitch and roll have been added, which eliminates the need for mechanical fly-bars, making the helicopters more stable and at the same time more manuervable since the fly bar no longer limits roll and pitch response. Similarly model aircraft pilots are using heading hold gyros for yaw control during takeoffs to deal with issues like p factor and gyroscopic reaction from the prop during pitch changes on tail draggers.

Getting back to the tire model, a similar type of pitch, yaw, and roll feedback process in the car and tire physics model would solve some of the issues with unrealistic responses of a modeled car at the limits. Yeah it's a "canned" fix, but one that can be accomplished in a reasonable amount of time.

I don't think your analogies fit here. What you refer to are actually means of control, sort of driving (flying) aids, not something that alters a physical model to be more realistic (since there is no "physical model", radio controlled models operate in "the real world", surely you're not proposing to hack real physics to be more realistic ? )

Also, while it is true that we can't expect a model to be realistic under all circumstances, what you propose is just to change a model to fit a "special case" which effectively means that you create another model - which still cannot be completely realistic. This is just one step of an infinitely recursive process, which has to be abandoned somewhere anyway, so in effect you have unfortunately said nothing useful to Scawen..

Stated in other words: IF you have a model with some flaws AND you know what should happen at the flawed state THEN you can incorporate that knowledge, so you can make a model that fixes the flaw. If you DON'T know what should happen at the flawed part, THEN a "canned" effect will not make your model much more realistic since, as already stated, you DON'T know what should happen.

Quote from CodieMorgan :

You cannot take propietary code and make it opensource

Why exactly?
Sure, it would kill the original business model, but what is it that says you "can't" do it?
(I'm not saying I would like to see the devs opensource the code, but I don't understand your argument)

Quote from tristancliffe :

Did you look at the rain video? Making wipers move and the track shiny in a repeating pattern whilst lowering overall grip and overall brighness does not, in my book, constitute rain simulation. I'm sure it'll be better than that, but not by much. I don't think it'll have puddles, dry and wet lines, varying conditions etc. Happy to be proven wrong though.

I don't know about the implementation, but Kunos had been experimenting with rain ages ago, and he did model water depth even then.

Quote from justasimfan :

The real feel is a pluggin that has been updated many times to include more force feedback effects.

The purpose - and merit - of the realfeel plugin is to export the actual forces acting on the steering rack, opposing the original ISI method of "magically" generating FFB from whatever sources. Realfeel actually proves that there is a sound physics engine at the basis of rFactor, and the last thing it needs is "effects"

Quote from justasimfan :

For god's shake people....they are supposed to be working for 2.5 years for....tire physics[...]

..Most developers _never_ get to the level of the current LFS tire physics, never mind in 2.5 years. And Scawen is trying to make it better. The effort of making something better, especially something that is already good, does not scale linearly with quality.

Quote from CodieMorgan :

You don't know what you are talking about!

Me, Slinger and Mat have taken about 3 years in development of OUR game - and we are only at 0.05. We are not even at alpha yet.

..And that's not even the most relevant comparison in Scawen's case.

Although it has been mentioned a few times, most people still fail to understand (especially non-coders) that it's often easier and faster to go from nil to some acceptable first version of a program than to improve on something that's already good. It's hard enough to insert new features into an ever-increasing code base, but to improve on some already existing code is very much non-linearly harder as the quality of the original code increases. This is not specific to software development of course: it's well known from economics that cost (time, money) rises ~exponentially with quality.

Quote from Juls :

Uh, sorry you are right, picked the wrong document

Here is the doc with actual measures. I uploaded it because I can't find any link to it anymore.
http://www.megaupload.com/?d=KDME226O

Load sensitivity (figure 4.6, 4.10,4.14, 4.18...E.2, E.3, E.5, E.8, E.9, E.12, E.13, E.16, E.17) is almost linear, with high friction coeff for low loads....never a convex shape like in ISI-based sims tyre files (assuming the three coeffs are what they are said to be in the comments).

I dare to hope they have more than 2 points of measure and don't call "measure" model-fitted data

BTW this document has other valuable things, like the speed sensitivity and the stiffness...pretty hard to find.
Amazing how tyre grip falls quickly with velocity...ISI-based sims use less dramatic values there too.

I haven't looked at the doc yet, so I may have wrong assumptions, but the case of _sliding_grip_ of rubber being a function of the sliding velocity is mentioned in a lot of publications. This does not mean that the max. grip varies similarly, although it seems logical to assume _some_ speed dependence there as well.

Actually two characteristics of rubber friction (rubber block, not a full tyre) appear often in publications, and with mostly the same formulae.
One is the speed dependence of the sliding friction (~1/(1+k*speed)), and the other is the load sensitivity of friction, which is *not* linear, but more like the graphs we see from LFS's model (~1/load^0.x).

While on this topic, I have seen 3 kinds of load sensitivity formulas for tyres, one as mentioned above, the other two being exponential decay and linear decay. It's true that I've not seen the rF type curve mentioned anywhere, but the load sensitivity curve points in RBR (although the scale is not clear there) don't seem to fit a "simple" mathematical formula either, and they are also supposed to be from measured data..

Quote from Juls :

Tyre load sensitivity (last chart in the document) for two unknown tyres, showing a straight line and a very important grip at low load.
http://www.optimumg.com/Optimu ... chTips/TireComparison.pdf

I don't know if you're aware, but that's not measured data, just the load sensitivity representation of the Pacejka '96 model:

Quote :

It is often useful to fit a tire model to the data –
even if we won’t do any simulation work. Comparing
two tire models instead of directly comparing the
raw data allows us to more easily see differences – the
model removes the experimental noise and test hysteresis
inherent in the raw data. Fitting a tire model
is a relatively simple task using OptimumT’s Model
Fitting Tool. For this example, we will fit Pacejka
Magic Formula ’96 models for both tires.

So that's "just another model".

Quote from PMD9409 :

You mistaked "the feel" with iR's content, not its physics. Put LFS' physics on iR's content, and I can promise it'll be better than what it is currently.

_different_, yes, _better_ - I personally don't think so. That's only subjective of course, but all arguments about "feel" are basically subjective.

Some things are for certain though, whether some things are off or not in iRacing, they sure have more data to prove the validity of their models.
Also, you cannot claim that LFS would produce "better" (more realistic) results with the iRacing data in the areas that it doesn't model, which is for one the majority of iRacing's cars' suspensions.

I think the dynamic response of LFS's road tyres (and probably the slicks too, but I can't judge that) is superior to mostly all other sims, but on the whole the experience is too similar between the different cars. I do not really fault the devs for that, but that's precisely where a lot of the (otherwise ridiculous amount of) money goes at iRacing: obtaining real-world data.

For me, it's quite an enlightening experience (and also a bit more believable in some circumstances) that I literally cannot complete my first lap in most of the cars in iRacing and yet end up racing quite reliably hardly an hour later. This means that the cars are quite noticeably different to one another, they are not trivial to drive, yet even a not very talented bloke like me can keep them on the track (and doesn't end up last ) after a little amount of getting used to.

But the main thing is that both LFS and iRacing are currently working on the most important aspect of a racing sim, the tyre model. And I'll be there to try both new models when they come out

From my personal experience as a sim developer, the dependence of a lot of tire model parameters on load is just about as important as the "flatness" of the slip angle curve beyond its peak. I currently use a simple variant of the brush model, and it's frustrating that most research papers don't really care about variations with load, or the effects are not described in detail.

On another note, one of the things I cannot really explain for myself from a physical point of view is why the longitudinal slip curve would have a peak and then fall when the lateral doesn't, or vice versa. From my understanding all of the contact patch is sliding at the long/lat peak, why would the long. force drop after that? Or, why wouldn't the lateral force drop? In my model the rubber friction coeff. drops slightly with sliding speed, this gives a reasonably small drop of lateral force, but also small, basicall no drop for the longitudinal force. If Todd would care to explain his take on this I would be eager to listen

Sorry for the late reply.

I would like to emphasize that I'm not claiming that the 'one-poll-per-frame' method would be the better solution, only that going more sophisticated may not be worth it for the developer/the issue itself.

Quote from amp88 :

Even with single core CPUs threading is a massively important process. The invention of multicore CPUs has brought the issue more into the public's eye, but threading was used long before that. Even with a single core CPU you can do multiple things at the same time (e.g. listen to an mp3 and drive in LFS).

Of course, multitasking makes sense. But there is a cost of a thread switch and as Ped7g wrote threading has a rather coarse granularity when we're looking at the millisec level.
Also it is not irrelevant whether the two threads are dependent on each other or not. In the case of controller polling/physics/frame display, they are not as independent as to have no effect on each other.

Quote :

Synchronisation isn't really that complicated an issue, especially for game developers. They already need to think about such things as multiplayer racing where the issue of synchronisation is more important.

That game developers need to solve difficult synchronization issues, is true of course. Multiplayer sync is a very good example.
But in general, it is not true that synchronization isn't that complicated, and game developers are not normally über-developers just because they happen to code games (Scavier being obvious exceptions, of course :tilt.
In general, one tries to tackle the programming tasks with the simplest solution that provides the expected results, that is the idea anyway. LFS is actually a good example as far as I can tell of a cautious approach: there are a lot of quite simple solutions in the engine (that make sense at the same time) and Scawen makes sure he really understands what he's doing when he goes deeper into something.

Quote :

I don't really understand the point you're trying to make. What I'm trying to say is that the controller input and the graphic display don't need to rely on each other. I think what you're trying to say is that if you can't see the result of your inputs (because of too much FPS lag) then those inputs should be ignored until the FPS has improved. Is that right?

No, I'm not saying that they should be ignored. I'm saying there is not much practical difference if you ignore them or not. I'm also saying that there is sense in the polling being connected somewhat to the frame rate, although one or more polls per frame is a different question.
Would have more to say but gotta go now..

Quote from amp88 :

Have the graphics and controller inputs on different threads (so they're independent of each other)? That way you can receive controller inputs even if you can't show the controller input in the graphics. The internal game model will still take account of the controller input though.

Yes, with the current multicore CPUs it does make more sense than before. But you will have to synchronize and make sense of a lot more complicated situation. It *seems* like a better idea but when you try to code it it may turn out to be not really worth it. I'm not saying it cannot be done intelligently, but consider this:

The fps rate will render the sim undrivable if it falls too low. You have a 1 frame lag during which you are driving in the dark, it does not make a too big difference in overall usability if you have multiple samples of the input during that time.
On the other hand, if you have very high fps, it doesn't make sense to poll the controller *less* frequently than the fps rate. In any case, you would want to do it as frequently as possible, why limit it if doesn't harm anything else?

Quote from amp88 :

That seems like a really bad way to do things. Have you got any articles or links as proof for that statement?

It does seem like an odd concept, but I don't know of a much better way to do it..

Quote from SamH :

Just to add to that, whatever framerate is being reported by LFS/FRAPS, the framerate being delivered to your eye is whatever Hz your monitor is running at. If your graphics card is cranking out 500fps but your monitor is running at 85Hz, then ONLY 85fps will pour out of your monitor. Anything FPS, in excess of the number of Hz, is just wasted cycles.

Not strictly true.
Yes, it is meaningless visually above a certain point, but it may make sense regarding the controller polling frequency. Not necessarily talking about LFS, but most sims' controller polling/FFB frequency is linked to fps. That can still mean a tiny difference above the visually meaningful range.

Quote from dev :

Less grip per tyre could actually result in more overall grip. You will have all 4 wheels doing the work in cornering (doe to less body roll), instead of the 2 outer tyres. It could easily happen that the inner tyres have more grip with "less grip physics" then they have now.

As somebody already explained before, all other things being equal, overall grip determines body roll and not the other way around
With the same ride height you cannot have more grip with "less roll", or more precisely: less weight transfer. If you lower the ride height though, you *might* end up very near the current lap times..

If the baseline grip level does not change much (which may well be the case from what Scawen wrote) then the result is unpredictable just now. "Less grip" generally means slower laps though.

Quote from Forbin :

The speed of the wheels doesn't change as fast when the car is on the ground, so I don't think it would be all that significant.

Actually from my experience it is, if you are doing a full multibody sim. AFAIK LFS uses a similar approach to RBR in that the wheels are not modeled as real (full) bodies. That said, RBR dips when applying the brakes in flight..

..When I changed my own model to use general multibody dynamics I first "forgot" to add a "retorque" from the brakes to the chassis.. The effect was very CMR-style handling.. Hardly any pitch from throttle or brake input and way too easy turning. Before that I had a relatively similar approach to LFS's older model that didn't take suspension geometry into account. Then, IIRC, the handling was similar to LFS in that I had correct pitching on the ground but not airborne.. The reason for the difference was that the actual forces between the tire and the road were transferred directly to the chassis (incorrect, but not by a huge factor) and when the car was airborne there were no forces between the tire and the ground to be transferred.. That's how I remember anyway..

Quote from tristancliffe :

Me neither. rFactor 'feels' (to me) like they tried to bodge it in to the sim, but ended up with snappy loss of grip and soft regaining... But that could be a host of other factors... NetKar is currently closest with it's beta version, although I'm not convinced that the latest version has gone in the right direction (though this is based on about 10 minutes of play time, and I'm not sure what setups I was running, but the FTarget felt very odd now, but it could be a leftover setup from a previous beta where I went a bit mad with my setup experimentation )

Generally I can't decide if it's a missing "effect" from the tire dynamic response or just a result of the slight but inevitable delay of the controllers. What I'm referring to (and I think you are, too, at least in part) is the situation where a starting slide is caught with very small steering input and the car immediately straightens, and does a little "wobble" before it settles. This might well be related to the much more direct feedback on the steering wheel IRL. Should try to find a video I guess..

Oh, one more thing: although the aligning moment of the tires is a relatively small factor, it does add to the straightening of the cars. Once the slip angles of the tires fall down from the full sliding regime, the aligning moment rises to help straighten the car. - But this part is easy to model and actually part of the tire models, so it shouldn't be a factor in the difference from sim and real life..

Quote from AndroidXP :

Bad example. First, the behaviour on dirt is very different than on tarmac. Second, that Evo actually hit something on the side of the road with its back, which is what made it spin around.

Actually the fishtailing Megane right after it may be a better example