what computers are iRacing designed for?

[darock]

Interesting post by an iRacing designer:

Originally Posted by Eric Hudec

Our math is just fine. It's your computers that's the problem.

[darock]

That was posted as an explanation of why some problems "can't be fixed".

They're not the first developer to market code that's beyond the hardware they're marketing to. They just might be the first to explain it so clearly in public.

[Chronus]

Originally Posted by darock

That was posted as an explanation of why some problems "can't be fixed".

They're not the first developer to market code that's beyond the hardware they're marketing to. They just might be the first to explain it so clearly in public.

Some people have an odd way of doing "humour"...

Regrettably.

[Kalifen]

Do you have a link to the post? Would be interesting to see the context.

Without knowing the context, I would assume he refers to physics calculations that currently would take too much time to compute on a normal computer. Also, he could be referring to how they may need to use low resolution variables instead of high resolution variables due to both computation time and being limited to 32bit platforms still. Or possibly that 100% simultaneous processing simply is not possible on current computers, meaning that objects/forces that should interfere perhaps get a bit skewed/delayed, causing strange and unpredictable effects. (Simple example: detect when a wheel hits a bump and calculate the effect - if the detection is slightly delayed, the bump may seem a lot harder due to the wheel sort of being "below surface" and having to correct more than if the bump had been detected 2 inches earlier)

In any case, meaning that currently their math can do the necessary computations for a "perfect" simulation, just it's not possible to perform it real time on a normal computer.

[Chronus]

And your definition of a "normal" computer?

We have multiple core, hyper-threaded cpus, some of them 64 bits, built with smaller then 45nm processes.

Seems to me, as very few people have seen the source code, there is a string possibility to use this "hardware can't handle it" excuse over and over.

And we should be reluctant to believe in it.

And before the usual fanboys jump the gun, I am referring to the "excuse", not the physics engine quality (which we know is slowly but surely improving along with other things).

[AllanGP]

Would love to see a link to the actual thread for context.

I did a poll and the vast majority (91%), would be happy to move to 64 bit exclusively given 6 months warning. 72% being already there.

If 64 bit was part of the answer I'd be giving the warning now. We have effectively had 3 months warning anyway, that's if they hit a roll out next build.

http://members.iracing.com/jforum/po...t/1976191.page

[Kalifen]

By normal I guess I mean mass produced for sale as a personal computer - even the awesome ones. Sorry, there are calculation that are too tough for the fastest pc in the store when keeping in mind we're talking real time.

When 32 bits and single/"few cores" don't need to be supported anymore, we will see good improvements (remember, physics must be calculated exactly the same way for everybody), but other stuff will have to wait many more years.

This stuff is equal for all racing titles, though, so if one title manages something, you can expect it to be possible to implement in another title as well.

[Chronus]

Obviously, real time processing requires fast hardware, I am not disputing that. But, and again we go back to an old discussion held here over a year ago: iRacing doesn't have to deal with AI. So, cpus are free from intensive calculations (AI behaviour plus the AI car physics) and free to deal with "human" cars only.

Hence why I said, we should not accept this excuse or justification by face value.

[Friedhelm7]

This is the thread:
http://members.iracing.com/jforum/po...t/2023021.page

As I read it, in some extreme situations the calculation steps are not enough, which may cause a numerical instability. But still better than "fake physics".

Other games fake it. If I wanted I could make it look like the car is on the ground, but I won't because it would be faked.

[brabham67]

Originally Posted by Chronus

Obviously, real time processing requires fast hardware, I am not disputing that. But, and again we go back to an old discussion held here over a year ago: iRacing doesn't have to deal with AI. So, cpus are free from intensive calculations (AI behaviour plus the AI car physics) and free to deal with "human" cars only.

Hence why I said, we should not accept this excuse or justification by face value.

That's a good point. I wonder how much CPU resources are used for AI in a game that has it. Most of the AI I have run against suck terribly. So maybe not much?

[Chronus]

Originally Posted by Friedhelm7

As I read it, in some extreme situations the calculation steps are not enough, which may cause a numerical instability. But still better than "fake physics".

With darock's permission (for probably addressing a lateral issue):

what do you mean, "fake physics"?

Don't quote anyone, just explain, please.

Originally Posted by brabham67

That's a good point. I wonder how much CPU resources are used for AI in a game that has it. Most of the AI I have run against suck terribly. So maybe not much?

I benchmarked this via "deactivating" AI code in a well known flight sim. It makes a big difference.

You don't need to have the source code and "neutralizing" AI code, though. All you have to do is monitor the use of resources (memory and cpu) with your car alone versus you car and a dozen AI cars.

Check it.

[AllanGP]

Originally Posted by Friedhelm7

This is the thread:
http://members.iracing.com/jforum/po...t/2023021.page

As I read it, in some extreme situations the calculation steps are not enough, which may cause a numerical instability. But still better than "fake physics".

Interesting thread. Eric's a great guy but sometimes some of his posts come out a bit "harsh" or lost in translation.

[Friedhelm7]

Originally Posted by Chronus

what do you mean, "fake physics"?

Don't quote anyone, just explain, please.

Here, in this special case, where as a result of the correct equations a wheel lifts in the air, because of numerical reasons, you could bypass the result of the calculation and make the wheel always stay on the ground.

[Chronus]

No, no.

You posted a quote:"Other games fake it. If I wanted I could make it look like the car is on the ground, but I won't because it would be faked. "

Then you write "still better than "fake physics"".

You could "bypass the result of the equation", true, but why would you? And how do you know that this has not happened? More over, how do you or others know that "other games fake it"?

Pretty much the same line of reasoning that tends to smear other "games" and safeguard the value of iRacing. Without proof, just, as Allan says above, "harsh" comments that serve little purpose other than "protecting" the work done by iRacing.

These boastful comparisons should never be acceptable. iRacing is a great product and service, stands on its own, no need to smear others with comments of "others fake it".

[Friedhelm7]

Chronus, read the thread in the iracing forum.
Why did Darock start this thread here?

BTW. Why do cars, which lift wheels quite a lot in the real world, never lift a wheel in GTL?

[Chronus]

Maybe Allan can post the thread here (he has kindly done so before), as he knows I am unable to access it.

Anyway, why did darock start this thread? Why, you mean he shouldn't have...?

BTW. Why do cars, which lift wheels quite a lot in the real world, never lift a wheel in GTL?

I'll put it as politely as possible: that is simply not true.

Hopefully, David Wright or Aris will explain it to you better than me.

[AllanGP]

Thread is too long to quote, I might try and find some essential bits but that will have to wait until tomorrow as I am off to the pub shortly

It was Eric who said he wasn't going to fake the physics to get the car to be have like it had properly working shocks, when they don't and that is due to the computational issues using big numbers. This is all about the fact that shocks on Oval cars are designed to have resistance to rebound once compressed but this does not work in iRacing properly.

I'm not explaining it too well so I will stop.

Also I think Eric can be quite "abrupt" in his comments, "harsh" was the wrong word.

Basically he knows so much about this stuff he can tend to be a bit dismissive and out of hand rather than taking the time to explain why the people are plonkers!

[Chronus]

rather than taking the time to explain why the people are plonkers!

Is he calling people plonkers (slang for "stupid person") or are you?

Hmmm...

Why are people "plonkers"? Can't they ask questions? Report probs? Complain about problems?

I suspect your choice of words (or his) betrays something you don't really wish to say, but even so it doesn't feel right.

It was Eric who said he wasn't going to fake the physics to get the car to be have like it had properly working shocks, when they don't and that is due to the computational issues using big numbers.

Well, Doug Arnao's suspension physics is regarded as a solid piece of work.

The same can be said about Racer, XMR and NKP.

So...who then is faking shock/suspension physics ("Other games fake it")?

[AllanGP]

"Plonkers" was my term.

What Eric has showed (though I don't understand it) is they have the calculations right but our computers are not good enough to do the calculations in real time to make it work.

[Kalifen]

Originally Posted by AllanGP

"Plonkers" was my term.

What Eric has showed (though I don't understand it) is they have the calculations right but our computers are not good enough to do the calculations in real time to make it work.

Basically iRacing (and others) use discrete steps for something that is continouos. That is how computers function. Generally that may or may not work out well. I assume that for iRacing many aspects work out well while a few struggle. Unfortunately, those will be the most visible ones, simply because they don't work out well. That's a downside of their "trying to calculate everything according to theory and not fudging numbers". If they one day succeed 100%, it will be rather awesome. In the meantime it's a personal preference if you want their partly faulty no-compromise approach or one with rather well-tuned fudging.

I assume increasing the physics refresh rate will help in many cases (but not all), when the customers' computers are ready for it.

Btw, LFS follow the same philosophy as iRacing, don't they?

[Chronus]

Originally Posted by Kalifen

That's a downside of their "trying to calculate everything according to theory and not fudging numbers".

What theory?

[AllanGP]

I have cut & paste consecutive Eric posts, hope they make sense;

The problem has only to do with lack of shock rebound preload damping, or also referred to as rebound nose in oval racing circles. Currently it is impossible to achieve even close to realistic rebound preload due to integration step limitations - the math would go crazy. Essentially our shocks have none whereas real stockcar shocks can have around 300 to 500 lbs at a typical short track. It's even possible to pass tech with as much as 1500 lbs in front rebound preload. That my friends is what holds the car down.

then

Our math is just fine. It's your computers that's the problem.

next

Has nothing to do with fast and slow speed damping. It has to do with mass and change in force. Big changes in force need large masses to not go numerically unstable with slow integration steps.

the bit I didn't understand

Play with this equation. You'll see what happens when you increase spring rate or damping coefficient but decrease mass and or integration step.

x1 = x0 + (v0 + v0')*0.5*(1/step rate) (m)

Where:
x0 = 0 (m)
x0' = x0+v0*(1/step) (m)
v0 > 0 (m/s) say 0.1 or 0.0001
v0' = v0 + a0*(1/step rate) (m/s)
v1 = v0+ (a0 + a0')*0.5*(1/step rate) (m/s)
a0 = (-Ks*x0 - Kd*v0)/M (m/s^2)
a0' = (-Ks*x0' - Kd*v0')/M (m/s^2)

Ks - spring constant (N/m)
Kd - damping coeff (N*s/m)
M - deflected mass (kg)
step rate - steps of math done per second (Hz)

then this response to a question

Jeremy Thornton wrote:
Sounds to me like it's time to rewrite the entire code for iRacing so the answer to almost everyones question isn't.. "We can't add this or that because it's not possible with the coding or physics."

I just can't comprehend that numerous games/sims can make just the little of things work in their games/sims, yet iRacing can't and is far behind for that simple fact. I quit racing all other online games because of the format that iRacing brings to the table. I just wish things would live up to the potential of what iRacing could be. Until that happens iRacing will still be a sub par game at best.

Eric
It has zero to do with your first part.

Other games fake it. If I wanted I could make it look like the car is on the ground, but I won't because it would be faked

In response to posts about faking it (Eric's last post in this thread so far);

How would it feel better? It would only look better but feel worse.

That's your lot I'm off for a pint!

[Chronus]

Jeremy Thornton is right, though, when he hints at the problem being in the physics.

The way iRacing simulates suspensions is not the only way to do it, nor is it necessarily the most correct or pure. It is just a method, just a collection of equations and algorithms that, as per Eric's own admission, doesn't work due to hardware limitations.

As Jeremy says, time to rewrite the code (not necessarily the ENTIRE code, I don't see DK doing such a massive mistake).

@Allan, thanks for (yet again) posting an interesting post from iRacing forums.

Enjoy your pint (don't over do it, though).

[darock]

Originally Posted by Chronus

What theory?

Since the design is entirely controlled by iRacing, they choose what theories to base their code on.

Apparently (based on Eric's statements) the ones they embrace either don't work (as proven in the thread) or are too intensive to be used. He isn't clear about whether they are using the equations he quoted (just as JK didn't when he laid out volumes of tire theory prior to the NTM release) or not using them.

The thread is also quite interesting in that at least one mathematician responded to Eric's "see why we can't do it" post with a way to do it. It's also interesting that noone has done a time trace on the "can't be done" equation. I'm guessing noone has the facility to do that. What a shame.

[darock]

Once upon a time, a computer mfg's application development group created an airline boarding system application. One piece of the puzzle was seat assignment. Passengers selected what kind of seating they desired/required and we applied that to the specific aircraft he would board. There were a lot of things to consider.

I gave the function to my senior senior programmer and provided him with an experienced programmer under him. It wasn't ready for inclusion to the beta release until the week the beta was to be provided to a customer airline. "Everything is working perfectly" rang in my ears as I handed off the tapes at the customer's computer center (in Europe). After a day of BSing with their BWs (BigWigs), I came back out that night to troubleshoot the install and testing. Damn........

Checking in any passenger was almost instantanious until a seat was requested with the transaction. Then their computer slowed down, the lights all over Frankfort airport dimmed and homes on that side of town lost power and the ILS on the runways quit. After awhile the transaction responded with a seat assignment.

It turns out my senior idiot had absolutely no limitations on any iteration in his code. The computers back then had just been released with multiple i-streams. They were sort of like our pc's today in architecture. Luckily, none of the VPs I'd been in conference with during the day had bothered to show up for the 1am run.

Luckily the site could run time traces. Those things are amazing. They clearly show where a transaction spends it's time. It's amazing how fast mathematical code runs. It's amazing how slow poor design can be.

[Chronus]

Originally Posted by darock

Since the design is entirely controlled by iRacing, they choose what theories to base their code on.

[...]

The thread is also quite interesting in that at least one mathematician responded to Eric's "see why we can't do it" post with a way to do it. It's also interesting that noone has done a time trace on the "can't be done" equation. I'm guessing noone has the facility to do that. What a shame.

I agree.

But we don't need to be in the know regarding the source code to understand why it doesn't work as expected. Obviously, provided that the equations used were indeed those reproduced above. Just look at the math up there. Not hard to see.

Another thing: the theory.

I have read/looked into the (many) possible ways of simulating tire behaviour under non-steady state conditions. Of course these calculations are intensive, regardless of the type of tire modelling. Developers/scientists look for ways to obtain the best results given the existing constraints (memory, computing power, etc). Ruud van Gaal, Gregor Veble, Brian Beckman discussed these issues (accuracy and computational resources) several times a decade or so ago, we're probably too aware that a balance of sorts has to be achieved between accuracy and performance and resources available.

But, obviously, if the means (math or algorithms) aren't accurate or present performance problems, they ought to be changed. It doesn't make much sense to simply say "hey, there really is no problem, our math is correct, problem is computers, so suck it up".

[darock]

When you design an application for sale to a specific market one important detail would be the range of performance you expect to encounter in that market. You then choose what functionality you will provide based on what can be done with their equipment and what your programmers can create.

[darock]

Originally Posted by Chronus

I agree.

But we don't need to be in the know regarding the source code to understand why it doesn't work as expected.

No foolin'

Interesting how often iRacing insiders come out from behind the curtain with a chalkboard and diagrams.

[darock]

Did anyone notice that buried within the chalk talk, was tacit admission that the shocks don't work.

[Chronus]

Originally Posted by darock

[...]

Luckily the site could run time traces. Those things are amazing. They clearly show where a transaction spends it's time. It's amazing how fast mathematical code runs. It's amazing how slow poor design can be.

Hehe.

It is curious how similar that experience is to my own - on multiple occasions.

You and I are probably NDA bound for years to come (I know I am), so specifics can't be discussed here.

But I found myself several times in situations where the math was perfect, the algorithms of the main classes were efficient but something failed somewhere down the line in a minuscule lib because someone wasn't careful enough to optimize a combination of iteration and conditional statements. It is surprising to see how grade-A level graduates (or post-graduates) stumble on the little things and create stupid problems.

EDIT:

time traces help. Problem is when the condition that triggers the "problem" is nonlinear or depends upon a conjugation of factors often difficult to replicate.

So, some managers, especially in defence contractors, rely heavily (I mean HEAVILY) on cyclomatic complexity to solve potential problems. Thing is, these oddities aren't always easy to predict and may not be spotted by high CC numbers.

Did anyone notice that buried within the chalk talk, was tacit admission that the shocks don't work.

Oh-oh, yeah indeed!

Originally Posted by Eric Hudec

Currently it is impossible to achieve even close to realistic rebound preload due to integration step limitations - the math would go crazy. Essentially our shocks have none whereas real stockcar shocks can have around 300 to 500 lbs at a typical short track

I really am not saying it is a simple job.

Nor am I saying that fixing the problem(s) is easy.

I just find it curious, from pCARS's AJ to iRacing's Hudec, the problems they're encountering seem a bit... odd.

[darock]

lol......

Haven't heard anyone talk like that in....... going on 16 years now.

Sad thing from my point of view is the game is the best online system yet. Oh wait.... going on 17 years. chuckle..... And am I glad for every day of those 17.

[Chronus]

1995/1996 was my beginning and in a big project (right there in North America).

Afterwards, ups and downs. IMHO, managing is the least attractive part of systems development (or IT in general), people aren't usually on the same page and often there's some (un)expected politics involved (especially between companies).

I suspect the world of simracing development nowadays is not a peaceful one - often, the best people aren't given enough time or resources to do a stellar job.

But that's me thinking out loud...

[MickeyMouse]

For a relevant layman's example, think of tire FEM. FEM is used by tire and car manufactures for tire simulation, but even on top end computers it takes many minutes to calculate just a few seconds, so compromises must be made if you want to run in real time. Instead of using FEM, brush and stretched string models must be used instead. They are arguably not as accurate as a full FEM model, but since it's simply impossible to use FEM at this time, their shortcoming just have to be tolerated until computer speed increases by a few orders of magnitude.

As for Eric's comments about integrator instability, that remind me of a short discussion a while ago I had with Scawen Roberts about LFS's spring integrator. He claims that LFS uses a two frequency Euler integrator, a high frequency (~2000 Hz) one for spring handling and a lower speed one for everything else. I personally can't imagine how that would work, but you can't argue with results, so perhaps iRacing should look into something like that.

[bozont]

there is a link for a video where a physics guy involved with gaming explain the whole problem about computational physics. (lol cant find it).

on the side of finite element method - static load of an very complex model (milions+- of elements) on with an old P2 400Mhz PC 1-2 minutes with enough ram . this is not interesting in gaming there is almost no static load when a car is moving.

fluid/air flow simulation - just a simple cylinder - a P4 took it an hour+ . - intersting for gaming

contact simulation - its even worse than fluid flow simulation. interesting for gaming too.

BMW stated in 2000 that they used pc's connected together with 200 cpu working together to simulate a car crash of 1:1 detailed model of the 5 series with LS Dyna (which should be the fastest solver of that time) . it took 2 weeks to compute just a head on crash. try this on 36+ cars

so the whole thing must be very very simplyfied to do it realtime-ish.

and dont forget the tires...

[AllanGP]

Originally Posted by darock

The thread is also quite interesting in that at least one mathematician responded to Eric's "see why we can't do it" post with a way to do it. It's also interesting that noone has done a time trace on the "can't be done" equation. I'm guessing noone has the facility to do that. What a shame.

Been through the thread a couple of times and can't see anyone posting a solution? Unless you are referring to Matt Holden's post which isn't a solution at all?

[Chronus]

Originally Posted by bozont

there is a link for a video where a physics guy involved with gaming explain the whole problem about computational physics. (lol cant find it).

Search for Brian Beckman & Forza - that is the interview.

The "physics guy" is Dr. Brian Beckman, a Physicist.

fluid/air flow simulation - just a simple cylinder - a P4 took it an hour+ . - intersting for gaming

contact simulation - its even worse than fluid flow simulation. interesting for gaming too.

This (car and tire behaviour, and on top collision physics) is obviously complex.

It is not as terrible as you make it look, though.

BMW stated in 2000 that they used pc's connected together with 200 cpu working together to simulate a car crash of 1:1 detailed model of the 5 series with LS Dyna (which should be the fastest solver of that time) . it took 2 weeks to compute just a head on crash. try this on 36+ cars

so the whole thing must be very very simplyfied to do it realtime-ish.

and dont forget the tires...

Taking your info at face value...

That was in 2000. So, either update the info or the comparison is no longer valid.

On the other hand, you are talking about a different thing than we are.

The goal of iRacing and the racing simulations we like is not to attempt to replace physics crash testing with a simulated one.

The goal here is racing simulation. Collision physics in simracing does not have to be ultra-sophisticated and ultra-complex - there really is no point in doing that. It is, however, rather good, in that it deals with chassis deformation, loss of wheels, loss of steering, loss of car body parts (prominently, aerodynamics apps), all of which are key to racing and how a race ends.

As for tires, Dr. Brian Beckman explained it quite well not only in that interview you allude to, but also in his racing physics series. There are, however, other experts, like Veble, Pacejka/Sharp/Bakker/Besselink, Gent, Assaad and Ebbon, the Millikens, all of which have contributed with their knowledge and in some capacity to the formulation of different tyre models (from Fiala to Swift and MF).

Iirc, most of these people have stated some compromises are necessary between complexity and accuracy.

Computational resources restrictions add up one more element to this, true, but the models used (math based, empirical based, physical based) in current simulations work and provide very good results - albeit not being 100% as accurate or effective as a multi-million dollar simulation developed by the likes of Mercedes.

[Kalifen]

Originally Posted by Chronus

Computational resources restrictions add up one more element to this, true, but the models used (math based, empirical based, physical based) in current simulations work and provide very good results - albeit not being 100% as accurate or effective as a multi-million dollar simulation developed by the likes of Mercedes.

Which brings us back to "Our math is just fine. It's your computers that's the problem"?

To fudge, or not to fudge, that is the question, when accuracy (that can be calculated on our computers) is not as desired. It seems iRacing always chooses not to fudge, or do any guess work for that matter (TC in the HPD, anyone?), and thus accepts certain flaws.

Again, when iRacing choose to focus on newer architecture and faster computers, ditching support for older ones, they will have the chance to increase frequency of physics calculations and make other relevant changes. That will solve/improve some cases (not all). Until then, we have to live with the flaws or hope that they find an actual solution based on mathematical theories. Or that there simply is a bug they can find and fix, which also happens from time to time of course.

Btw, I guess that also their math has been and most likely still is wrong here and there. I base this on the fact that they keep evolving their cars with tweaks to aerodynamic effects, weight distribution, tires etc. Otherwise the cars should feel rather similar from season to season, right?

[AllanGP]

In Dave K's long NTM post he said that there was no point in fixing the physics until the NTM was right and the NTM wouldn't be right until we had both NTM & NSM.

Given some cars have been updated it would seem iRacing are trying to move forward before the NTM and NSM are right. I'm kind of interested/suspicious that suddenly we were told the 64 bit was being worked on very hard and it might even be with us next build, maybe there is a link?

The only thing that goes against that is the fact they will still (apparently) support 32 bit users. I certainly hope they are not going to artificially cripple the 64 bit version to keep it in line with the 32 bit version.

The next two builds could just define iRacing's future and what it holds for us all.

[darock]

Originally Posted by Kalifen

Which brings us back to "Our math is just fine. It's your computers that's the problem"?

Btw, I guess that also their math has been and most likely still is wrong here and there. I base this on the fact that they keep evolving their cars with tweaks to aerodynamic effects, weight distribution, tires etc. Otherwise the cars should feel rather similar from season to season, right?

You've mentioned something there that cannot be ignored.

iRacing continually changes. Every release gets howls and crying over how cars suddenly do things differently. So when has the "math been fine"? Which release was it correct? Correct doesn't change.

What all of us need to do is accept that it hasn't been perfectly correct and probably won't be for a very long time if ever. They don't have to be perfect to be good. And if you've ever watched some of the iRacing moon shot videos you know their definition of 'fine' can be far from it. If your opinion of the latest version of your favorite iRacing car is that it is perfect now, what was it last release, and what will it be next one.

The idea that it's our computers really shows that some of them really don't understand the business. Their only market is nothing but our computers.

[Kalifen]

Originally Posted by AllanGP

The only thing that goes against that is the fact they will still (apparently) support 32 bit users. I certainly hope they are not going to artificially cripple the 64 bit version to keep it in line with the 32 bit version.

The only option I see viable with two versions living side by side is to allow for better graphics for 64 bit systems, while keeping the physics "32 bit compatible" for yet another while.

[Chronus]

Originally Posted by Kalifen

To fudge, or not to fudge, that is the question, when accuracy (that can be calculated on our computers) is not as desired. It seems iRacing always chooses not to fudge, or do any guess work for that matter (TC in the HPD, anyone?), and thus accepts certain flaws.

Which brings us back to tire models (especially) and, in particular, to the Pacejka/Bakker models.

When people talk about this or that racing sim, based on isiMotor2, which uses variations on Pacejka's work, and they talk about "fudging" they most certainly do not know what they're talking about. Not saying that is your case, but I have read one too many posts and whole threads here, RD, simHQ or even iRacing forums, about why Pacejka tire models are wrong and "fantasy", when in fact things are not like that. At all.

People need to look at the theory, reasoning and math behind it, understand why and how these have become standards of tire industry, and understand how the models/formulas work. Usually, hearsay and biased opinions dictate people's views on racing sims other than iRacing.

And we end up right here: DK's NTM is just a model, it is not THE model, it is not the ultimate word on tire modelling. It...is...just...a...model, probably no more perfect or imperfect than others. But people (fanboys, mostly) still don't get this.

Again, when iRacing choose to focus on newer architecture and faster computers, ditching support for older ones, they will have the chance to increase frequency of physics calculations and make other relevant changes. That will solve/improve some cases (not all). Until then, we have to live with the flaws or hope that they find an actual solution based on mathematical theories. Or that there simply is a bug they can find and fix, which also happens from time to time of course.

Agreed.

Btw, I guess that also their math has been and most likely still is wrong here and there. I base this on the fact that they keep evolving their cars with tweaks to aerodynamic effects, weight distribution, tires etc. Otherwise the cars should feel rather similar from season to season, right?

If we think about the reasons WHY the NTM (or the entire physics engine) is evolving, we have to see it that way:
- DK finds something about the code algorithms that might prevent the accuracy he seeks
- DK finds something in the math algorithms that needs improvement or correction
- DK implements a new physics effect; this may have collateral consequences
- performance issues: improving code, optimizing it

[SternRav0R]

Originally Posted by Kalifen

The only option I see viable with two versions living side by side is to allow for better graphics for 64 bit systems, while keeping the physics "32 bit compatible" for yet another while.

There in lies the crux of the problem. I know of no Gamer/Simmer that still runs a 32bit Only CPU in this day and age. If you are then you are not playing any titles that were released in the last 5 years. Both AMD(x64 in 2003) and Intel(IA64 in 2004) stopped doing 32bit only CPU's nearly a Decade ago.

Devs need to stop screwing around, get with the times and throw away their 32bit Compilers.

[AllanGP]

Is it a CPU issue or and OS issue?

[SternRav0R]

Originally Posted by AllanGP

Is it a CPU issue or and OS issue?

Does it really matter? If you want a DX11 title you have to have Win7 at least anyway, why bother buying the 32bit version when teh 64bit version cost the same and performs faster, which Microsoft insists that OEM PC Mfgs install the 64 bit versions for new machines. Same with Windows 8, 64bit only on new licenses for new machine is what they insist on. Why they even bothered with a 32bit version of Win8 is beyond me.

Apps run faster when they can address more than 1GB of Ram if needed(32bit Windows limitation that doesn't allow an app to have more than 1GB at time, although you can hack around that limit). Either way I find it highly annoying that the Software dev world is taking longer to adapt to 64bit than it took the transition from 16 to 32bit. When Win95 was released that pretty much killed the 16bit app dev days. Win7 should have been the death knell for 32bit apps, but it hasn't.

[AllanGP]

What I meant was by implication most people will have 64 bit capable cpu's but if they don't have 64 bit OS's they can't take advantage?

It does mean however upgrading for most would be a simple OS upgrade not a hardware upgrade, much cheaper.

[bozont]

Originally Posted by Chronus

Search for Brian Beckman & Forza - that is the interview.

The "physics guy" is Dr. Brian Beckman, a Physicist.

oops, my bad

that video shows how they use all the math voodoo they came off to look it very real, but with less info and cpu/gpu power, Ram needed. so it sometimes can go wrong....

after some googling around , it seems the LS dyna got really fast on todays CPU, they tested it on dual core Xeon. went down to 52xx seconds for a three car crash.

in few years it could be even realtime lol.

http://www.anandtech.com/Show/Index/...ge-for-servers

[Hotsocks]

Originally Posted by Chronus

Which brings us back to tire models (especially) and, in particular, to the Pacejka/Bakker models.

When people talk about this or that racing sim, based on isiMotor2, which uses variations on Pacejka's work, and they talk about "fudging" they most certainly do not know what they're talking about. Not saying that is your case, but I have read one too many posts and whole threads here, RD, simHQ or even iRacing forums, about why Pacejka tire models are wrong and "fantasy", when in fact things are not like that. At all.

People need to look at the theory, reasoning and math behind it, understand why and how these have become standards of tire industry, and understand how the models/formulas work. Usually, hearsay and biased opinions dictate people's views on racing sims other than iRacing.

Ok. So why are DaveK and Scawen wringing their brains out with trying to make an alternative work? Do you think it's just for convenience of not curve fitting lots of tires in different conditions? For it is they who say - or at least Dave K did - that what he had before didn't deal with the full range of extreme behaviour under race conditions. I even remember someone on the FSAE tire testing consortium saying he didn't like Pacejka because it was difficult to fit for all 3 standard situations at the same time commonly tested.

And before you go off on another wobbly - I'm not claiming knowledge nor do I study this stuff. So don't get all authoritarian/authoritative because someone might express a different opinion to your own. I for one make no apology for repeating what people who're more familiar with this stuff have said e.g. Niels Heusinkveld who does the physics now for Reiza, said a while back - around the time of his popular Corvette rR mod - that in view of a particular problem (apparently) for sim developers in combining longitudinal and lateral forces (identified by Todd Wasson), he thought then that accurate tire data wasn't necessarily that crucial because he had no idea how ISI had combined the slip ratio (longitudinal) and slip (lateral) effects. Don't know if he still stands by that but that's what he said a few years back. The point being you could get dead accurate results from Pacejka for forces/moments during slip with no slip ratio, or longitudinally with no lateral slip, which is why industry use it, but combining them, you got different answers.

Comments? I'm not trying to argue something, just trying to find out if this makes sense to you.

[Chronus]

Originally Posted by Hotsocks

Ok. So why are DaveK and Scawen wringing their brains out with trying to make an alternative work?

I read articles or posts by both explaining what they were trying to achieve. Their whys don't concern me. Their business, not mine.

And before you go off on another wobbly - I'm not claiming knowledge nor do I study this stuff. So don't get all authoritarian/authoritative because someone might express a different opinion to your own.

You are obviously not really interested in having a nice, productive discussion (as are others here, regardless of any of us agreeing with each other), otherwise you wouldn't make those comments.

As you wish.

[Hotsocks]

I was interested in your opinion actually. But never mind.

[SternRav0R]

Originally Posted by AllanGP

What I meant was by implication most people will have 64 bit capable cpu's but if they don't have 64 bit OS's they can't take advantage?

It does mean however upgrading for most would be a simple OS upgrade not a hardware upgrade, much cheaper.

You just summed up nicely what I was trying to say. heheh
Yes, an O/S upgrade would be required to take advantage of a pure 64bit app environment. There are a few 32bit WinXP hold outs out there still. But even that came in a 64bit version.

Personally speaking I only use the 64bit version of apps when available on my systems. Like the right now, I'm using FireFox 64 to write this -- http://www.firefox64bit.com/