Explanation of GPL physics engine

Hey there, Does anyone know how much detail has ever been released about the GPL physics engine? I remember someone once talking about the number of times per second the physics were recalculated, but I can't find anything now. Can any of you help me find anything at all technical to do with the GPL engine? Thanks very much, Tom

Sorry Tom I don't have much info for you, but I can tell you that the GPL physics engine is designed to run at 288 Hz (i.e. 8 updates per frame at 36 frames per second). Don't know what frequency the controller is read at - I'd guess it's also at 288 Hz but maybe it's less..... I believe the physics engine ignores the effects of kingpin inclination (or maybe it's the caster angle that's missed out, I forget). This was discussed a while ago in a thread about steering away from slides, but I can't find it at the moment for you. Google.com is a good place to start to search the r.a.s. back catalogue for more technical info, good luck HTH JimSeamus "Tom Steinberg" <[email hidden]> wrote in message news:[email hidden]...

Quoted text (10 lines)

> Hey there, > Does anyone know how much detail has ever been released about > the GPL physics engine? I remember someone once talking about the > number of times per second the physics were recalculated, but I can't > find anything now. Can any of you help me find anything at all > technical to do with the GPL engine? > > Thanks very much, > > Tom

Jim(s) Caster is modeled. You can feel it with a FF wheel. --Steve Smith "Jim L" <[email hidden]> wrote in message news:BjFM6.15701$[email hidden]... > > Sorry Tom I don't have much info for you, but I can tell you that the GPL > physics engine is designed to run at 288 Hz (i.e. 8 updates per frame at36 > frames per second). Don't know what frequency the controller is read at - > I'd guess it's also at 288 Hz but maybe it's less..... > > I believe the physics engine ignores the effects of kingpin inclination(or > maybe it's the caster angle that's missed out, I forget). This wasdiscussed > a while ago in a thread about steering away from slides, but I can't findit > at the moment for you. > > Google.com is a good place to start to search the r.a.s. back cataloguefor

Quoted text (20 lines)

> more technical info, good luck > > HTH > JimSeamus > > > "Tom Steinberg" <[email hidden]> wrote in message > news:[email hidden]... > > Hey there, > > Does anyone know how much detail has ever been released about > > the GPL physics engine? I remember someone once talking about the > > number of times per second the physics were recalculated, but I can't > > find anything now. Can any of you help me find anything at all > > technical to do with the GPL engine? > > > > Thanks very much, > > > > Tom > >

There's just one of me :0) I use JimSeamus as a name in vroc but Jim L is how my OE is set up, just to confuse you..... Caster would be the cause of the "auto straightening" when you release the wheel, no? Haven't got a FF device myself. I guess it's kingpin inclination that doesn't get modelled in GPL in that case, which AFAIK is the "backwards" angle as opposed to the "inboard" caster angle - does this make any sense? Cheers JimSeamus / Jim L "Stephen Smith" <[email hidden]> wrote in message news:ahOM6.94716$%[email hidden]...

Quoted text (10 lines)

> Jim(s) > > Caster is modeled. You can feel it with a FF wheel. > > --Steve Smith > > "Jim L" <[email hidden]> wrote in message > news:BjFM6.15701$[email hidden]... > > > > Sorry Tom I don't have much info for you, but I can tell you that the

GPL > > physics engine is designed to run at 288 Hz (i.e. 8 updates per frame at > 36 > > frames per second). Don't know what frequency the controller is readat -

Quoted text (7 lines)

> > I'd guess it's also at 288 Hz but maybe it's less..... > > > > I believe the physics engine ignores the effects of kingpin inclination > (or > > maybe it's the caster angle that's missed out, I forget). This was > discussed > > a while ago in a thread about steering away from slides, but I can't

find

Quoted text (27 lines)

> it > > at the moment for you. > > > > Google.com is a good place to start to search the r.a.s. back catalogue > for > > more technical info, good luck > > > > HTH > > JimSeamus > > > > > > "Tom Steinberg" <[email hidden]> wrote in message > > news:[email hidden]... > > > Hey there, > > > Does anyone know how much detail has ever been released about > > > the GPL physics engine? I remember someone once talking about the > > > number of times per second the physics were recalculated, but I can't > > > find anything now. Can any of you help me find anything at all > > > technical to do with the GPL engine? > > > > > > Thanks very much, > > > > > > Tom > > > > > >

No, as you can see from the few responses, no one here can help you. Not a surprise to some of us. David G Fisher "Tom Steinberg" <[email hidden]> wrote in message news:[email hidden]...

Quoted text (10 lines)

> Hey there, > Does anyone know how much detail has ever been released about > the GPL physics engine? I remember someone once talking about the > number of times per second the physics were recalculated, but I can't > find anything now. Can any of you help me find anything at all > technical to do with the GPL engine? > > Thanks very much, > > Tom

>No, as you can see from the few responses, no one here can help you. Not a >surprise to some of us. WTF is *that* supposed to mean? -- Dale Earnhardt, Sr. R.I.P. 1951-2001 Homepage - http://www.umich.edu/~epickett F1 hcp. +25.37...F2 +151.26... Never argue with an idiot. He brings you down to his level, then beats you with experience... Remove SPAM-OFF to reply.

>"David G Fisher" <[email hidden]> wrote > No, as you can see from the few responses, no one here can help you. Not a > surprise to some of us. So? What do you expect? That we give him the Papy SDK and every detail of the game engine? What's your point? -- -- Fran�ois M�nard <ymenard> -- May the Downforce be with you... -- http://www.ymenard.com/ -- This announcement is brought to you by the Shimato Dominguez Corporation - helping America into the New World...

>"David G Fisher" <[email hidden]> wrote > No, as you can see from the few responses, no one here can help you. Not a > surprise to some of us. Oh and of course, we aren't surprised that YOU can't help either <G> -- -- Fran�ois M�nard <ymenard> -- May the Downforce be with you... -- http://www.ymenard.com/ -- This announcement is brought to you by the Shimato Dominguez Corporation - helping America into the New World...

RAS' Einstein is alluding to a discussion some time back as to why a deluded minority in RAS seems to believe the GPL physics engine is technically superior to other games' efforts. As he was unwilling to disclose his inside knowledge of other developers physics engines, "we" clammed up on what is public knowledge about GPL: ie. 6 dof, car simulated as a collection of "3D" objects with forces acting along the orientation of the actual links between them (instead of their effect being calculated at certain nodes) and a simulation rate of more than 200Hz. DGF abandoned the discussion when ymenard and myself became pushy in this respect, especially with respect to the lack of longitudinal roll inertia in and exact simulation rate of RC2000. There are limitations to the GPL/N4 model, of course, a knod to keeping it all real time. There is a certain effort involved not to blatantly exploit them, but all in all it gives me the most "consistent" experience. Jan. =--- "Pay attention when I'm talking to you boy!" -Foghorn Leghorn. EldredP wrote... > >No, as you can see from the few responses, no one here can > help you. Not a surprise to some of us. > > WTF is *that* supposed to mean?

Jan, He asked, "Does anyone know how much detail has ever been released about the GPL physics engine?" and, "Can any of you help me find anything at all technical to do with the GPL engine?" Your answer does not go into very much detail and is not very technical. Questions as to what the makes the GPL physics sooooo much better than anything else have always been answered in a vague manner because no one really knows the details. Never have. Never will. Tell me, what makes the GPL physics engine "better" than F1RC's? Technical details please. Do you know the technical details of both physics engines? BTW, I know where a person can simply purchase and download a physics engine made by a team of 50 physicists, mathematicians and computer programmers located in Oxford, England and five other facilities around the world. Of course, they probably don't have a 1/4 of the knowledge the Papyrus employees do. David G Fisher "Jan Verschueren" <[email hidden]> wrote in message news:[email hidden]... > RAS' Einstein is alluding to a discussion some time back as to why adeluded > minority in RAS seems to believe the GPL physics engine is technically > superior to other games' efforts. > > As he was unwilling to disclose his inside knowledge of other developers > physics engines, "we" clammed up on what is public knowledge about GPL:ie. > 6 dof, car simulated as a collection of "3D" objects with forces acting > along the orientation of the actual links between them (instead of their > effect being calculated at certain nodes) and a simulation rate of morethan > 200Hz. DGF abandoned the discussion when ymenard and myself became pushyin

Quoted text (18 lines)

> this respect, especially with respect to the lack of longitudinal roll > inertia in and exact simulation rate of RC2000. > > There are limitations to the GPL/N4 model, of course, a knod to keeping it > all real time. There is a certain effort involved not to blatantly exploit > them, but all in all it gives me the most "consistent" experience. > > Jan. > =--- > "Pay attention when I'm talking to you boy!" -Foghorn Leghorn. > > EldredP wrote... > > >No, as you can see from the few responses, no one here can > > help you. Not a surprise to some of us. > > > > WTF is *that* supposed to mean? > >

Download?!? Fastcar costs about $20,000 for gods sake. You may be able to download but you sure can't produce anything with it without paying Oxford Dynamics a vast sum of money. "David G Fisher" <[email hidden]> wrote in message news:NkZM6.1458$[email hidden]... > Jan, > > He asked, "Does anyone know how much detail has ever been released about > the GPL physics engine?" and, "Can any of you help me find anything atall

Quoted text (11 lines)

> technical to do with the GPL engine?" > > Your answer does not go into very much detail and is not very technical. > Questions as to what the makes the GPL physics sooooo much better than > anything else have always been answered in a vague manner because no one > really knows the details. Never have. Never will. > > Tell me, what makes the GPL physics engine "better" than F1RC's? Technical > details please. Do you know the technical details of both physics engines? > > BTW, I know where a person can simply purchase and download a physics

engine > made by a team of 50 physicists, mathematicians and computer programmers > located in Oxford, England and five other facilities around the world. Of > course, they probably don't have a 1/4 of the knowledge the Papyrus > employees do. > > David G Fisher

FastCar is still being worked on ( www.oxforddynamics.co.uk) ... but does seem pretty good so far. Functionality is being added farily frequently and it does seem to run quite fast. That reminds me ... must shoehorn FastCar into my code to see if i can get it to run. It is difficult without seeing the code to say exactly what any of the sims do. The frequency of the physics engine is more tuned to stability than accuracy. Although by definition, an engine updating at a higher rate should be more accurate. One of the guys working on a personal sim is updating the wheels at around 3000 Hz due to the lack of mass in the wheel objects. The majority of details known about various games comes from interviews and looking at the files. You can get a good idea of what scgt and f12000 et al do by looking at the veh files and seeing what variables they have. As to the differences between gpl and F1RC, personally I couldn't say as the cars are too different to judge side by side. my 2c Shane Lowry David G Fisher <[email hidden]> wrote in message news:NkZM6.1458$[email hidden]... > Jan, > > He asked, "Does anyone know how much detail has ever been released about > the GPL physics engine?" and, "Can any of you help me find anything atall

Quoted text (11 lines)

> technical to do with the GPL engine?" > > Your answer does not go into very much detail and is not very technical. > Questions as to what the makes the GPL physics sooooo much better than > anything else have always been answered in a vague manner because no one > really knows the details. Never have. Never will. > > Tell me, what makes the GPL physics engine "better" than F1RC's? Technical > details please. Do you know the technical details of both physics engines? > > BTW, I know where a person can simply purchase and download a physics

engine

Quoted text (27 lines)

> made by a team of 50 physicists, mathematicians and computer programmers > located in Oxford, England and five other facilities around the world. Of > course, they probably don't have a 1/4 of the knowledge the Papyrus > employees do. > > David G Fisher > > "Jan Verschueren" <[email hidden]> wrote in message > news:[email hidden]... > > RAS' Einstein is alluding to a discussion some time back as to why a > deluded > > minority in RAS seems to believe the GPL physics engine is technically > > superior to other games' efforts. > > > > As he was unwilling to disclose his inside knowledge of other developers > > physics engines, "we" clammed up on what is public knowledge about GPL: > ie. > > 6 dof, car simulated as a collection of "3D" objects with forces acting > > along the orientation of the actual links between them (instead of their > > effect being calculated at certain nodes) and a simulation rate of more > than > > 200Hz. DGF abandoned the discussion when ymenard and myself became pushy > in > > this respect, especially with respect to the lack of longitudinal roll > > inertia in and exact simulation rate of RC2000. > > > > There are limitations to the GPL/N4 model, of course, a knod to keeping

it > > all real time. There is a certain effort involved not to blatantlyexploit

Quoted text (14 lines)

> > them, but all in all it gives me the most "consistent" experience. > > > > Jan. > > =--- > > "Pay attention when I'm talking to you boy!" -Foghorn Leghorn. > > > > EldredP wrote... > > > >No, as you can see from the few responses, no one here can > > > help you. Not a surprise to some of us. > > > > > > WTF is *that* supposed to mean? > > > > >

I wasn't referring to Fastcar. David G Fisher "Simon Brown" <[email hidden]> wrote in message news:kNZM6.3446$[email hidden]... > Download?!? Fastcar costs about $20,000 for gods sake. You may be ableto

Quoted text (18 lines)

> download but you sure can't produce anything with it without paying Oxford > Dynamics a vast sum of money. > > "David G Fisher" <[email hidden]> wrote in message > news:NkZM6.1458$[email hidden]... > > Jan, > > > > He asked, "Does anyone know how much detail has ever been released about > > the GPL physics engine?" and, "Can any of you help me find anything at > all > > technical to do with the GPL engine?" > > > > Your answer does not go into very much detail and is not very technical. > > Questions as to what the makes the GPL physics sooooo much better than > > anything else have always been answered in a vague manner because no one > > really knows the details. Never have. Never will. > > > > Tell me, what makes the GPL physics engine "better" than F1RC's?

Technical > > details please. Do you know the technical details of both physicsengines? > > > > BTW, I know where a person can simply purchase and download a physics > engine > > made by a team of 50 physicists, mathematicians and computer programmers > > located in Oxford, England and five other facilities around the world.Of

Quoted text (7 lines)

> > course, they probably don't have a 1/4 of the knowledge the Papyrus > > employees do. > > > > David G Fisher > > >

...so you were refering to...? "David G Fisher" <[email hidden]> wrote in message news:gUZM6.1504$[email hidden]... > I wasn't referring to Fastcar. > > David G Fisher

Sorry Simon, I wasn't trying to be coy. Distractions all around me here tonight. The company is called MathEngine. David G Fisher "Simon Brown" <[email hidden]> wrote in message news:X_ZM6.3512$[email hidden]...

Quoted text (10 lines)

> ...so you were refering to...? > > "David G Fisher" <[email hidden]> wrote in message > news:gUZM6.1504$[email hidden]... > > I wasn't referring to Fastcar. > > > > David G Fisher > > >

I presume you mean either MathEngine's 'Karma' or 'Vortex' by Critical Mass Labs, a subsidiary of MathEngine. Either way, it really doesn't matter how good their libraries are, or how talented their physicists, mathematicians and programmers are, since they don't write games and you can't buy any racing sims based on their code. What MathEngine might be capable of doesn't make GPL any less realistic, or make any other game any more realistic. Also based on how professional their website looks, I'd say their products are likely to be even more expensive than Fastcar. I don't see the point you are trying to make. Why does it matter whether they know more or less than Papy about writing physics simulations, since they don't make computer games. I'm not going to comment on F1RC because I haven't seen it, but as for every other racing game/sim I *have* seen, the only two products that I would class as 'simulations' and not just 'games' are GPL and N4. "David G Fisher" <[email hidden]> wrote in message news:R1_M6.1507$[email hidden]... > Sorry Simon, I wasn't trying to be coy. Distractions all around me here > tonight. The company is called MathEngine. > > David G Fisher

Stephen, are you sure? I always felt as if only aligning torque was modelled but that caster was is if it was 0 (esp. since when you turn the wheel a lot there is a point of the force actually starting to push into the direction you are turning). Then again, you probably know better what's really happening than I do. :) -Gregor Stephen Smith wrote:

Quoted text (7 lines)

> > Jim(s) > > Caster is modeled. You can feel it with a FF wheel. > > --Steve Smith >

Hi David, those who claim that the core physics engine is sooo much better than anything else are surely wrong. However, the GPL and, furthermore, the N4 engine sure are the most refined car physics engines used in entertainment software to this day. I would say that, in the majority of the titles we consider sims these days, the core of the physics engine is largely the same, meaning that it's a rigid body model with 6DOF with forces/torques acting on it. But the refinements of the tyre, drivetrain (esp. differential) and subtle interactions between parts is what sets them apart. However, if that was all that was to it, most people wouldn't even notice. What is, I believe, more important is how this physics model is presented to the player, which means how the feedback is handled. This goes for graphics (head movement), sound (tyre squeal at the proper point) and actual force feedback, and this is what makes the experience of the physics engine the best in GPL and Nascar 4, and in fact it is also the reason why I prefer GP3 to the feel of any other modern F1 sim. The modern F1 sims really aren't all that different in fidelity and if slightly tweaked can to some extent be made to respond quite similarly, but the 'feel' will be vastly different because the most difference just might be in the feedback part. Also, it takes a lot of knowledge and ingeniuity to create a widely general physics engine (such as the one you mention), but for a, let's face it, relatively simple problem such as car simulation, a general University course in physics and maths is quite adequate, especially since the knowledge on how to do it is widely available. Sure, more knowledge can help you to find the most optimal ways of doing it, but it's mostly overkill in a problem like this. -Gregor David G Fisher wrote:

Quoted text (23 lines)

> > Jan, > > He asked, "Does anyone know how much detail has ever been released about > the GPL physics engine?" and, "Can any of you help me find anything at all > technical to do with the GPL engine?" > > Your answer does not go into very much detail and is not very technical. > Questions as to what the makes the GPL physics sooooo much better than > anything else have always been answered in a vague manner because no one > really knows the details. Never have. Never will. > > Tell me, what makes the GPL physics engine "better" than F1RC's? Technical > details please. Do you know the technical details of both physics engines? > > BTW, I know where a person can simply purchase and download a physics engine > made by a team of 50 physicists, mathematicians and computer programmers > located in Oxford, England and five other facilities around the world. Of > course, they probably don't have a 1/4 of the knowledge the Papyrus > employees do. > > David G Fisher >

On Fri, 18 May 2001 11:26:03 +0200, Gregor Veble <[email hidden]> wrote: <snip> >However, if that was all that was to it, most people wouldn't even >notice. What is, I believe, more important is how this physics model is >presented to the player, which means how the feedback is handled. This >goes for graphics (head movement), sound (tyre squeal at the proper >point) and actual force feedback, Too bad F1RC has none of these :( <snip rest of excellent post> Andre

On Fri, 18 May 2001 00:29:37 GMT, "David G Fisher" <[email hidden]> wrote: >Sorry Simon, I wasn't trying to be coy. Distractions all around me here >tonight. The company is called MathEngine. Geesh, just because you have a computer doesn't mean you can create a nice game. Just because you have a physics engine doesn't mean you can create a racing game. GPL has a great feel, that's why most people will agree that it feels technically the most advanced. On the other hand, GPL doesn't use wings, and wings take frequency (the 288Hz) because all frequencies in the car tend to go up (stiffer springs, tires, motions etc). This *does* make GPL a perfect example of what physics models can feel like; I have N4 (didn't see it in the shops in Holland, but got it from cdexpress.nl for a minor amount of cash) but I must say I can't really find back the same feel in that game as I did with GPL. However, in what sim can you steer your car by rotating your (spinning) wheels in the air? For example. Car sim designers themselves regard GPL as top of the bill, and they know what they're doing. What's wrong with that? I can also say that we're all in the Matrix and none of you are alive and probably just the latest Turing simulation exe from Donald Knuth, but that doesn't matter; it's the reality as *I* see it, as *I* experience it. I can always say that it may be completely different, but that's no use as you don't feel it. Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Free car sim : http://www.marketgraph.nl/gallery/racer/

On Fri, 18 May 2001 10:14:12 +1000, "Shane Lowry" <[email hidden]> wrote: >FastCar is still being worked on ( www.oxforddynamics.co.uk) ... but does >seem pretty good so far. Functionality is being added farily frequently and >it does seem to run quite fast. That reminds me ... must shoehorn FastCar >into my code to see if i can get it to run. I don't believe you can just try it in your source; it's not really for free. >accuracy. Although >by definition, an engine updating at a higher rate should be more accurate. >One of the guys working on a personal sim is updating the wheels at around >3000 Hz due >to the lack of mass in the wheel objects. I would say, catch a grip on the lack of mass. At 100Hz, my tires are doing reasonably fine, although I think at 250Hz the jitters become invisible. But ofcourse this highly depends on how you're doing things, not trying to boast. >The majority of details known about various games comes from interviews and >looking at the files. You can get a good >idea of what scgt and f12000 et al do by looking at the veh files and seeing >what variables they have. Yep. Like 'slow_rebound' and fast_Rebound. You can tell by looking at that that there's no curve for example (it's the suspension rate when compressing/extending). So you know how it is implemented fairly accurately. The sim physics are not so complicated by themselves, it's the combination of a lot of them that makes the stuff work. >As to the differences between gpl and F1RC, personally I couldn't say as the >cars are too different to judge side by side. Right, GPL has the wonderful attribute in that it is able to *EXPOSE* its physics model more clearly, as motion are slower in general (frequencies, like car bouncing up and down). This gives a great feel. Winged cars are much more jumpy. Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Free car sim : http://www.marketgraph.nl/gallery/racer/

David G Fisher wrote... > <snip> > Your answer does not go into very much detail and is not > very technical. I wasn't answering the original posters question, I was answering Eldred's question. And yes, I do have a tendency to speak in a non-technical manner about technical subjects. Bit of a one man campaign to demistify technology and electronics/computers in particular actually. These subjects really aren't *that* difficult for the average person to understand, but there exists this "language barrier" around them. > Questions as to what the makes the GPL physics sooooo much > better than anything else have always been answered in a > vague manner because no one really knows the details. Never > have. Never will. We know even less of the inner workings of other games, but that's not really important. Even if you treat them as black boxes, there is a lot of information that can be gleaned from their interaction with the user. To me, and I imagine to others too, GPL gives me the most believable experience and throws up the least number of inconsistencies with the real world as I understand and perceive it. Ergo it's, IMO, the best simulation regardless of how it was made and I'm willing to take the developers' word for it some of the reason for this is because of the "technical" parameters I outlined in my post. Continued below your next comment > Tell me, what makes the GPL physics engine "better" than > F1RC's? Technical details please. Do you know the technical > details of both physics engines? The point is: neither do you, or you do and are unwilling to share the data. If I experience one of the aforementioned inconsistencies in sim X, and go on draw a certain conclusion on how this sim relates to GPL from this incident, I'm going on circumstantial evidence, true. But unless you can present just as valid circumstantial or hard evidence of the contrary, it will be hard to dissuade me from that position. You have yet to produce *any* riposte other than "unless we have details on both simulation we can never be sure". This might be sufficient in the academic sense, but it's just not the way things work in the real world (e.g. try rationalizing against the fear of GM foods). I therefore hold you have no reason to, by extention, call me stupid, immature and emotionally unstable just because, IMO, GPL still is the benchmark racing simulation. I will forgo on a comparison to F1RC... I haven't had a chance to drive it yet. > BTW, I know where a person can simply purchase and download > a physics engine made by a team of 50 physicists, mathematicians > and computer programmers located in Oxford, England and five > other facilities around the world. Of course, they probably don't > have a 1/4 of the knowledge the Papyrus employees do. Pity we can't simply purchase and download a real-time, multiplayer racing simulation game from them. Jan. =---- "Pay attention when I'm talking to you boy!" -Foghorn Leghorn.

David G Fisher wrote: > > No, as you can see from the few responses, no one here can help you. Not a > surprise to some of us. And I can't help either...if that makes you any happier. Gerry "He said I said that when he said what he said." -- David G Fisher

Quoted text (10 lines)

>>accuracy. Although >>by definition, an engine updating at a higher rate should be more accurate. >>One of the guys working on a personal sim is updating the wheels at around >>3000 Hz due >>to the lack of mass in the wheel objects. > >I would say, catch a grip on the lack of mass. At 100Hz, my tires are >doing reasonably fine, although I think at 250Hz the jitters become >invisible. But ofcourse this highly depends on how you're doing >things, not trying to boast.

Hmmm... You two talkin' about me? :-) Ruud, shame on you. Just because you figured out how to make SAE555..whatever work and I still haven't got around to it ;-) My rotations are stable and fine at about the same frequencies you're talking about. I crank mine up to 3000Hz so I can switch to the low-speed ring-type model at a lower speed, and it doesn't slow things down enough to notice yet anyway. I should take another look at later though and prevent any possible overkill. The 30,000- 60,000 Hz was for radio controlled car tires, which don't like 100 to 250 (or even 3000Hz) very much at all :-). Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

Heya JT ... your name slipped my mind there :) ... I remembered that due to the lack of mass of the RC wheels that you had to crank the engine freq. FastCar is free to evaluate, but it takes a stamp of your HD so you can't distribute the code ... can't even move it to another drive. Seems ok ... but 20k is a little steep for a hobby project so I'll just write my own :) ... we might even end up with a nice little community of physics experts. regards Shane "J. Todd Wasson" <[email hidden]> wrote in message news:[email hidden]... > >>accuracy. Although > >>by definition, an engine updating at a higher rate should be moreaccurate. > >>One of the guys working on a personal sim is updating the wheels ataround

Quoted text (9 lines)

> >>3000 Hz due > >>to the lack of mass in the wheel objects. > > > >I would say, catch a grip on the lack of mass. At 100Hz, my tires are > >doing reasonably fine, although I think at 250Hz the jitters become > >invisible. But ofcourse this highly depends on how you're doing > >things, not trying to boast. > > Hmmm... You two talkin' about me? :-) Ruud, shame on you. Just

because > you figured out how to make SAE555..whatever work and I still haven't got > around to it ;-) > > My rotations are stable and fine at about the same frequencies you'retalking > about. I crank mine up to 3000Hz so I can switch to the low-speedring-type > model at a lower speed, and it doesn't slow things down enough to noticeyet > anyway. I should take another look at later though and prevent anypossible

Quoted text (10 lines)

> overkill. The 30,000- 60,000 Hz was for radio controlled car tires, which > don't like 100 to 250 (or even 3000Hz) very much at all :-). > > > Todd Wasson > --- > Performance Simulations > Drag Racing and Top Speed Prediction > Software > http://PerformanceSimulations.Com

On 18 May 2001 23:12:50 GMT, [email hidden] (J. Todd Wasson) wrote:

Quoted text (14 lines)

>>>accuracy. Although >>>by definition, an engine updating at a higher rate should be more accurate. >>>One of the guys working on a personal sim is updating the wheels at around >>>3000 Hz due >>>to the lack of mass in the wheel objects. >> >>I would say, catch a grip on the lack of mass. At 100Hz, my tires are >>doing reasonably fine, although I think at 250Hz the jitters become >>invisible. But ofcourse this highly depends on how you're doing >>things, not trying to boast. > > Hmmm... You two talkin' about me? :-) Ruud, shame on you. Just because >you figured out how to make SAE555..whatever work and I still haven't got >around to it ;-)

Sorry Todd. ;-) I didn't really figure out SAE950311. I've thrown it out for lateral forces. I still use the longitudinal one, but use a different kind of damping; when 'u' reverses sign. Works much better (see v0.4.5, just released). But you don't have mass in the wheels then?? Surely there's inertia... > My rotations are stable and fine at about the same frequencies you're talking >about. I crank mine up to 3000Hz so I can switch to the low-speed ring-type >model at a lower speed, and it doesn't slow things down enough to notice yet >anyway. I should take another look at later though and prevent any possible >overkill. The 30,000- 60,000 Hz was for radio controlled car tires, which >don't like 100 to 250 (or even 3000Hz) very much at all :-). Ah yes. I noticed 250Hz will get away with jittering here. Note that I do wheel velocity reversal detection; when the sign of the wheel velocity changes, I hold on to the speed and set it at either -0.0001 or +0.0001 depending on what direction it was going. This works quite well; I had problems otherwise when pressing the brakes. Now I just let the brake torque rise up and it gives me no trouble. Ouch, groceries! Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Free car sim : http://www.marketgraph.nl/gallery/racer/

Quoted text (23 lines)

>>>>accuracy. Although >>>>by definition, an engine updating at a higher rate should be more >accurate. >>>>One of the guys working on a personal sim is updating the wheels at around >>>>3000 Hz due >>>>to the lack of mass in the wheel objects. >>> >>>I would say, catch a grip on the lack of mass. At 100Hz, my tires are >>>doing reasonably fine, although I think at 250Hz the jitters become >>>invisible. But ofcourse this highly depends on how you're doing >>>things, not trying to boast. >> >> Hmmm... You two talkin' about me? :-) Ruud, shame on you. Just because >>you figured out how to make SAE555..whatever work and I still haven't got >>around to it ;-) > >Sorry Todd. ;-) >I didn't really figure out SAE950311. I've thrown it out for lateral >forces. I still use the longitudinal one, but use a different kind of >damping; when 'u' reverses sign. Works much better (see v0.4.5, just >released). >But you don't have mass in the wheels then?? Surely there's inertia... >

No mass in the wheels, so vertical tire spring rate doesn't effect anything unless I combine the "wheel rate" with a sequential spring system using both rates. I do use rotational moments of inertia though! ;-) Gotta have it!

Quoted text (14 lines)

>> My rotations are stable and fine at about the same frequencies you're >talking >>about. I crank mine up to 3000Hz so I can switch to the low-speed ring-type >>model at a lower speed, and it doesn't slow things down enough to notice yet >>anyway. I should take another look at later though and prevent any possible >>overkill. The 30,000- 60,000 Hz was for radio controlled car tires, which >>don't like 100 to 250 (or even 3000Hz) very much at all :-). > >Ah yes. I noticed 250Hz will get away with jittering here. Note that I >do wheel velocity reversal detection; when the sign of the wheel >velocity changes, I hold on to the speed and set it at either -0.0001 >or +0.0001 depending on what direction it was going. This works quite >well; I had problems otherwise when pressing the brakes. Now I just >let the brake torque rise up and it gives me no trouble.

Interesting how you set the velocities this way. Instead, I check for reversal and set the state to "locked" for that tire. After that, each time through the loop, if it's still locked, it checks to see if the torque at the wheel is greater than the torque applied by the brakes. If it isn't, it stays locked, if it is, it unlocks it and lets it rotate according to both forces. This works great. I also do the same thing for the clutch, so any torque capacity clutch can be used and there aren't any instabilities. Gotta remember to tighten the clutch when you put a huge engine in, or it slips. This got me a couple times! I thought the tires were spinning, but the car kept going straight anyway. Whoops.. >Ouch, groceries! > Hehe. I gotta eat soon..... Must... eat...fooood.... Too....much....programming...... :-P BTW, I got sound working through the Waveout.. functions (now using OpenGL like you, although nowhere near as pretty). I play around with algorithms that produce some pretty cool sound that varies according to throttle and rpm. This gives a totally different sound when you're under trailing throttle, kind of a "braaaaaap" sound. Still, I think it'll be awhile before I can give Staccato a run for their money ;-) Soon, I'll need to get one of my old wave action engine simulation projects up and running again and try running the exhaust pressure data throw the sound buffers. Will let you know how it sounds :-) Any idea how I can run a wav file this way? Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

On 19 May 2001 23:21:39 GMT, [email hidden] (J. Todd Wasson) wrote: ... >>But you don't have mass in the wheels then?? Surely there's inertia... > > No mass in the wheels, so vertical tire spring rate doesn't effect anything >unless I combine the "wheel rate" with a sequential spring system using both >rates. But the wheel rate is similar to the tire rate isn't it? (although you can combine the two, sure). > I do use rotational moments of inertia though! ;-) Gotta have it! Phew!

Quoted text (12 lines)

>>Ah yes. I noticed 250Hz will get away with jittering here. Note that I >>do wheel velocity reversal detection; when the sign of the wheel >>velocity changes, I hold on to the speed and set it at either -0.0001 >>or +0.0001 depending on what direction it was going. This works quite >>well; I had problems otherwise when pressing the brakes. Now I just >>let the brake torque rise up and it gives me no trouble. > > Interesting how you set the velocities this way. Instead, I check for >reversal and set the state to "locked" for that tire. After that, each time >through the loop, if it's still locked, it checks to see if the torque at the >wheel is greater than the torque applied by the brakes. If it isn't, it stays >locked, if it is, it unlocks it and lets it rotate according to both forces.

Hm, yes, it's similar, although I do that implicity by letting the wheel jump back & forth between -0.0001 and +0.0001. I must see, I have some differential code in which outputs accelerations rather than torques (formulas courtesy Gregor Veble), so you input the engine torque, plus the 2 torques (reactions, so Brakes+RollingResistance+RoadReaction) from the wheels attached to the diff, calculate a locking torque (limited slip diff), and out comes the accelerations on all 3 ends. Works great, it seems. :) Problem is so that I don't get a TORQUE at the wheel, but an acceleration, so I can't decide whether it locks or not; the *differential* decides that. >This works great. I also do the same thing for the clutch, so any torque >capacity clutch can be used and there aren't any instabilities. Gotta remember >to tighten the clutch when you put a huge engine in, or it slips. This got me >a couple times! I thought the tires were spinning, but the car kept going >straight anyway. Whoops.. Hm, have to remember this for the future. :) The clutch is still a bit of misery in my code. >>Ouch, groceries! >> > > Hehe. I gotta eat soon..... Must... eat...fooood.... >Too....much....programming...... :-P Food & a life. Oh, sorry, I was talking about ME. ;-) > BTW, I got sound working through the Waveout.. functions (now using OpenGL >like you, although nowhere near as pretty). I play around with algorithms that >produce some pretty cool sound that varies according to throttle and rpm. This >gives a totally different sound when you're under trailing throttle, kind of a >"braaaaaap" sound. Still, I think it'll be awhile before I can give Staccato a >run for their money ;-) Well, but still, it's your own. More rewarding. And more flexible. Sounds good that you have sound working. :) > Soon, I'll need to get one of my old wave action engine simulation projects >up and running again and try running the exhaust pressure data throw the sound >buffers. Will let you know how it sounds :-) Any idea how I can run a wav >file this way? I have no idea. I don't know about Waveout, but I direct DirectSound to push memory buffers out the machine. This way you can do your own memory buffer juggling if you want. But for now, it's just simple looping waves. Sound definitely could use an upgrade in Racer. Collision hits, road sound, grass sound (and grass surface detection)... Geez. Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Free car sim : http://www.marketgraph.nl/gallery/racer/

Hi, as I see my name mentioned I think I can add a comment here :). After talking with Chris, it became obvious to me that the locking (as explained here by Todd) is the way to go, and that's precisely how I handle it now (and so does Chris, but he did it for a long time :) ). This, however, affects the functioning of the differential. When one wheel is locked, one needs to explicitly tell the differential this is the case and revert to another set of equations there (where one acceleration is explicitly set to 0), and then do a check on the torque produced in the differential as to whether it 'unlocks' the wheel. Therefore I have four different ways of handling the differential, depending on how many of the two wheels are locked. BTW, the acceleration of an assembly and the total torque on it are really interchangeable, and only the multiplication/division by the effective moment of inertia of that assembly that stands between them :). -Gregor Ruud van Gaal wrote:

Quoted text (13 lines)

> > Hm, yes, it's similar, although I do that implicity by letting the > wheel jump back & forth between -0.0001 and +0.0001. I must see, I > have some differential code in which outputs accelerations rather than > torques (formulas courtesy Gregor Veble), so you input the engine > torque, plus the 2 torques (reactions, so > Brakes+RollingResistance+RoadReaction) from the wheels attached to the > diff, calculate a locking torque (limited slip diff), and out comes > the accelerations on all 3 ends. Works great, it seems. :) > Problem is so that I don't get a TORQUE at the wheel, but an > acceleration, so I can't decide whether it locks or not; the > *differential* decides that. >

Quoted text (9 lines)

>>>But you don't have mass in the wheels then?? Surely there's inertia... >> >> No mass in the wheels, so vertical tire spring rate doesn't effect >anything >>unless I combine the "wheel rate" with a sequential spring system using both >>rates. > >But the wheel rate is similar to the tire rate isn't it? (although you >can combine the two, sure).

It depends on the car I suppose. I'm not really sure. It sure looks like most cars don't flex too much at the tires. The engineers at the RC car company I'm working with said the tire only compresses 1mm for each 8mm suspension movement. It's probably better to do it your way, but with this ratio I'd need to up the sampling quite a bit. Again, I'm not sure what the ratio is on full size cars, and I haven't tried sequential springing it anyway yet. I figure, since full suspension modeling isn't there yet, it won't mess it up any more than it already is.

Quoted text (11 lines)

>Hm, yes, it's similar, although I do that implicity by letting the >wheel jump back & forth between -0.0001 and +0.0001. I must see, I >have some differential code in which outputs accelerations rather than >torques (formulas courtesy Gregor Veble), so you input the engine >torque, plus the 2 torques (reactions, so >Brakes+RollingResistance+RoadReaction) from the wheels attached to the >diff, calculate a locking torque (limited slip diff), and out comes >the accelerations on all 3 ends. Works great, it seems. :) >Problem is so that I don't get a TORQUE at the wheel, but an >acceleration, so I can't decide whether it locks or not; the >*differential* decides that.

Same thing here :-) Torque bias ratio and preload are used too, and out comes acceleration directly, skipping torque. Sounds like we're on the same page. Gregor's quite the mathematical genius though, I'm sure his method is more efficient than mine.

Quoted text (14 lines)

>> BTW, I got sound working through the Waveout.. functions (now using OpenGL >>like you, although nowhere near as pretty). I play around with algorithms >that >>produce some pretty cool sound that varies according to throttle and rpm. >This >>gives a totally different sound when you're under trailing throttle, kind of >a >>"braaaaaap" sound. Still, I think it'll be awhile before I can give >Staccato a >>run for their money ;-) > >Well, but still, it's your own. More rewarding. And more flexible. >Sounds good that you have sound working. :) >

Just got some tire squealing in last night. It's just some random sine wave frequencies that jump around in a range that sounds as close to your skid sound as I could get. The engine sound is pretty cool IMO, probably because I'm proud. Everyone else would think it was pretty cheesy though! lol

Quoted text (14 lines)

>> Soon, I'll need to get one of my old wave action engine simulation >projects >>up and running again and try running the exhaust pressure data throw the >sound >>buffers. Will let you know how it sounds :-) Any idea how I can run a wav >>file this way? > >I have no idea. I don't know about Waveout, but I direct DirectSound >to push memory buffers out the machine. This way you can do your own >memory buffer juggling if you want. But for now, it's just simple >looping waves. >Sound definitely could use an upgrade in Racer. Collision hits, road >sound, grass sound (and grass surface detection)... Geez. >

I think it works the same way. I write the data directly to the sound buffers and play them. This is cool because you can put together functions that end up overflowing the integer sine wav. For some reason, it sounds just like the older games with good digital sound, only now it changes with throttle. I'd still love to run the Ferrari sound from GPL though :-) Do you know the Wav format at all? Are they random access files where the sound data begins at a certain record number, then is straight amplitude data vs. time for the rest of the file? Hmm... If I can "decode" it, it should be easy to mess with it. Heck, I'd settle for just playing one! Right now, the only way I can do it is with SndPlaySound (is that right? It's been awhile.) Of course then, you can't change the frequency :-( Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

Quoted text (22 lines)

>Hi, > >as I see my name mentioned I think I can add a comment here :). > >After talking with Chris, it became obvious to me that the locking (as >explained here by Todd) is the way to go, and that's precisely how I >handle it now (and so does Chris, but he did it for a long time :) ). > >This, however, affects the functioning of the differential. When one >wheel is locked, one needs to explicitly tell the differential this is >the case and revert to another set of equations there (where one >acceleration is explicitly set to 0), and then do a check on the torque >produced in the differential as to whether it 'unlocks' the wheel. >Therefore I have four different ways of handling the differential, >depending on how many of the two wheels are locked. > >BTW, the acceleration of an assembly and the total torque on it are >really interchangeable, and only the multiplication/division by the >effective moment of inertia of that assembly that stands between them >:). > >-Gregor

Great timing, Gregor. I just had this happen last night for the first time. The car stopped, and the wheels went nuts. It happened after I changed the cut off speed for the low speed tire model and lowered the tire inertia by a factor of four... Will have to check it out, I knew this would happen..... BTW, you guys are handling limited slip diffs by keeping the differential locked until the specified torque bias and preload are exceeded, then letting the wheels accelerate away from each other according to the "clutch" torque indicated by the ratio in torques across the diff, right? This works really well, it keeps the torque bias right on all the time. Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

Hi Todd, currently I only have an open type differential implemented with a viscous coupling. But if I did the proper locking, I would approach it exactly the same way as you do. -Gregor "J. Todd Wasson" wrote:

Quoted text (13 lines)

> > BTW, you guys are handling limited slip diffs by keeping the differential > locked until the specified torque bias and preload are exceeded, then letting > the wheels accelerate away from each other according to the "clutch" torque > indicated by the ratio in torques across the diff, right? This works really > well, it keeps the torque bias right on all the time. > > Todd Wasson > --- > Performance Simulations > Drag Racing and Top Speed Prediction > Software > http://PerformanceSimulations.Com

J. Todd Wasson <[email hidden]> wrote in message news:[email hidden]... > It depends on the car I suppose. I'm not really sure. It sure lookslike > most cars don't flex too much at the tires. The engineers at the RC car Can I ask which company that is? > company I'm working with said the tire only compresses 1mm for each 8mm > suspension movement. It's probably better to do it your way, but withthis And what class of car are you using: 1/10th, 1/8th, on-road foam, on-road rubber, off-road? > ratio I'd need to up the sampling quite a bit. Again, I'm not sure whatthe > ratio is on full size cars, and I haven't tried sequential springing itanyway > yet. I figure, since full suspension modeling isn't there yet, it won'tmess > it up any more than it already is. Just curious! Jonny

On 21 May 2001 22:25:36 GMT, [email hidden] (J. Todd Wasson) wrote:

Quoted text (8 lines)

>>Problem is so that I don't get a TORQUE at the wheel, but an >>acceleration, so I can't decide whether it locks or not; the >>*differential* decides that. > > Same thing here :-) Torque bias ratio and preload are used too, and out >comes acceleration directly, skipping torque. Sounds like we're on the same >page. Gregor's quite the mathematical genius though, I'm sure his method is >more efficient than mine.

Stupid thing of me; ofcourse acceleration is directly related to torque through inertia. Was away for work when I realised it, duh, as Gregor pointed out. Anyway, I'll rethink the wheel locking thing. Real work is beginning to swamp me again, and weather is getting nicer again; time for some time off and enjoy the sun. :) If I'm correct then though, keeping the braking torque as it is now might get me incorrect accelerations using Gregor's original diff eq's. But what for nearly locked wheels? This will be nearly equal to a locked wheel, right? I'll have to look for overshooting the torques and getting bad results when braking hard. Might be another fat bug to squash. ... > Just got some tire squealing in last night. It's just some random sine wave >frequencies that jump around in a range that sounds as close to your skid sound >as I could get. The engine sound is pretty cool IMO, probably because I'm >proud. Everyone else would think it was pretty cheesy though! lol On the C64, everything sounded cool as well, but only now do I realise that most people could plainly hate it. ;-) But ANY engine sound is cool, as long as it pitches. :) ...

Quoted text (10 lines)

>>Sound definitely could use an upgrade in Racer. Collision hits, road >>sound, grass sound (and grass surface detection)... Geez. >> > > I think it works the same way. I write the data directly to the sound >buffers and play them. This is cool because you can put together functions >that end up overflowing the integer sine wav. For some reason, it sounds just >like the older games with good digital sound, only now it changes with >throttle. I'd still love to run the Ferrari sound from GPL though :-) Do you >know the Wav format at all?

Check out the source docs from Racer on my site; find QLib/qsample.cpp; there's a piece of Wave loading down below. You'll need WINMM.LIB I guess for some functions. > Are they random access files where the sound data >begins at a certain record number, then is straight amplitude data vs. time for >the rest of the file? Try not to do it this way; it's a RIFF format (much like Apple's IFF); very flexible. Now on to real work, things are getting tight next week. Too tight for fun. And at times like these, it's my phone that's crashed (well, the central operation one, but that one won't reset), and my MS-Word and printer makes my computer crash. Great! :( Back to the Unix machine, ahhh. :) Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Free car sim : http://www.marketgraph.nl/gallery/racer/

>> It depends on the car I suppose. I'm not really sure. It sure looks >like >> most cars don't flex too much at the tires. The engineers at the RC car > >Can I ask which company that is? > Not just yet, I'd rather wait until it's released. (Sorry :-)) >And what class of car are you using: 1/10th, 1/8th, on-road foam, on-road >rubber, off-road? It's on-road, but I forget exactly which scale and tire the 8:1 ratio was for and can't find the blasted email that told me this! >Just curious! No problem, wish I could give more info :-) Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

Quoted text (8 lines)

> >Hi Todd, > >currently I only have an open type differential implemented with a >viscous coupling. But if I did the proper locking, I would approach it >exactly the same way as you do. > >-Gregor

Great. It's nice when I finally do something right! Thanks, Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

Quoted text (16 lines)

>>>Problem is so that I don't get a TORQUE at the wheel, but an >>>acceleration, so I can't decide whether it locks or not; the >>>*differential* decides that. >> >> Same thing here :-) Torque bias ratio and preload are used too, and out >>comes acceleration directly, skipping torque. Sounds like we're on the same >>page. Gregor's quite the mathematical genius though, I'm sure his method is >>more efficient than mine. > >Stupid thing of me; ofcourse acceleration is directly related to >torque through inertia. Was away for work when I realised it, duh, as >Gregor pointed out. >Anyway, I'll rethink the wheel locking thing. Real work is beginning >to swamp me again, and weather is getting nicer again; time for some >time off and enjoy the sun. :) >

Well, it was quite a revelation to me when I discovered it could be done directly this way rather than trying to calculate the actual driving torque at each wheel independently, then derive acceleration from that afterwords, so I know what you meant. Not stupid at all :-) As far as the weather goes, I suppose if I had any sort of life at all, I'd be out enjoying it now too ;-) >If I'm correct then though, keeping the braking torque as it is now >might get me incorrect accelerations using Gregor's original diff >eq's. But what for nearly locked wheels? This will be nearly equal to >a locked wheel, right? I'll have to look for overshooting the torques >and getting bad results when braking hard. Might be another fat bug to >squash. I haven't seen his diff equations and haven't tried a viscous differential yet, so I really don't know what to say for that. I do know that I'll need to take another look at how I'm locking the wheels across the differential though. I plan on still using either totally locked or unlocked states and checking to see if torque from slip ratio is enough to overpower the brakes before they are allowed to unlock again. This works really well so far, but it does need another close look to make sure it's really right. When the car's stopped, the wheels may want to rotate in opposite directions. I figure you might as well stick to how you're doing it now since the tire data isn't going to be spot on with a locked wheel anyway. I suppose this does let the slip ratio equations work, since the wheel velocity never actually hits zero. Now, I check for this with an IF statement set which probably isn't as fast as your method. >Check out the source docs from Racer on my site; find >QLib/qsample.cpp; there's a piece of Wave loading down below. You'll >need WINMM.LIB I guess for some functions Ok, I'll do that, thanks.

Quoted text (13 lines)

>> Are they random access files where the sound data >>begins at a certain record number, then is straight amplitude data vs. time >for >>the rest of the file? > >Try not to do it this way; it's a RIFF format (much like Apple's IFF); >very flexible. > >Now on to real work, things are getting tight next week. Too tight for >fun. And at times like these, it's my phone that's crashed (well, the >central operation one, but that one won't reset), and my MS-Word and >printer makes my computer crash. Great! :( >Back to the Unix machine, ahhh. :)

I'll have to check on the RIFF thing too. Unix? What's that? ;-) Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com