Hi there,
I'm adding some variables to my car model, while reading 'Fundamentals
of Vehicle Dynamics' from Thomas Gillespie. Well, actually, I'm
converting the body and wheels to rigid body classes which use
quaternions and inertia tensors for their rotation (so I have faster
functions and gyroscopic precession for free for all the
forces/torques I want to add) (this 'simplified' model will allow
easier inclusion of new forces/torques in a more clean way).
Anyway, in the book, Gillespie follows the engine torque to the
wheels, and does it like this:
Te=point on the engine's torque curve
Tc=Te-IeAe
where Tc=torque at the clutch, Ie=rotational inertia of the engine,
and Ae=engine rotational acceleration.
Td=Tc-...
Ta=Td-...
(Td=torque output to the driveshaft, Ta=torque on the axles)
So he keeps subtracting torque in every step, based on the
acceleration. Now in simulation, the acceleration is *the question*,
rather than the answer to fill in the equations. It seems I can't use
these formula's like that.
It seems to me that since everything is fixed together, the torque
remains the same, but all inertia of all connected components must be
taken into account, so:
totalInertia=I_engine+I_driveshaft+I_transmission+I_rearaxle(RWD)+...
torque=Te
And then calculate rotational acceleration by torque/totalInertia
(taking into account the transmission's torque multiplier ofcourse).
Right?
The differential will probably be the most problematic part, where I
have to model how it will allow both axle outputs to rotate (which
means the totalInertia might change if the diff locks up more or
less).
This problem looks a lot like what I had once before, namely the
rotation of the wheels; what influence the drivetrain inertia has
together with the wheels on the total change of the engine's rpm. That
was mainly solved by just applying the torque and using the slip ratio
model.
But it seems strange to me what Gillespie writes, namely that torque
*decreases* as it moves from engine to the wheels. At least his
formula's imply so.
Any thoughts? Thanks,
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Car simulation: http://www.marketgraph.nl/gallery/racer/
Drivetrain effective inertia in car physics models
Ruud van Gaal asked how to account for engine and drivetrain rotational inertias using Gillespie's equations. Matthew Jessick, J. Todd Wasson, Bob Norton and Gregor Veble discussed effective inertia, drivetrain efficiency and gear ratios, with Wasson correcting his own formula. Months later the thread continued with van Gaal's article on effective inertia, track splines, combined slip, third-spring suspensions and the DOF file format of his Racer project.
physics/realism debateRacer
Automated summary.
When tracking the torque through a gearset the gearing changes the
torques, of course. What's nearly constant is the power. There is a
loss in power (due to friction), but otherwise the power stays
constant through gearsets, but not torque.
When thinking of the engine driving the wheels, the fricitional losses
always cause a drop is power when going from the source (engine) to
the point of interest (wheels). When under engine braking the
fricitional losses will continue to be dissipative. In this case the
power under engine braking will be higher at the wheels, smaller at
the engine.
Bob
On Fri, 02 Feb 2001 10:16:57 GMT, [email hidden] (Ruud van Gaal)
wrote:
Quoted text (57 lines)
>Hi there, > >I'm adding some variables to my car model, while reading 'Fundamentals >of Vehicle Dynamics' from Thomas Gillespie. Well, actually, I'm >converting the body and wheels to rigid body classes which use >quaternions and inertia tensors for their rotation (so I have faster >functions and gyroscopic precession for free for all the >forces/torques I want to add) (this 'simplified' model will allow >easier inclusion of new forces/torques in a more clean way). > >Anyway, in the book, Gillespie follows the engine torque to the >wheels, and does it like this: > >Te=point on the engine's torque curve >Tc=Te-IeAe > where Tc=torque at the clutch, Ie=rotational inertia of the engine, >and Ae=engine rotational acceleration. > >Td=Tc-... >Ta=Td-... > >(Td=torque output to the driveshaft, Ta=torque on the axles) > >So he keeps subtracting torque in every step, based on the >acceleration. Now in simulation, the acceleration is *the question*, >rather than the answer to fill in the equations. It seems I can't use >these formula's like that. >It seems to me that since everything is fixed together, the torque >remains the same, but all inertia of all connected components must be >taken into account, so: > >totalInertia=I_engine+I_driveshaft+I_transmission+I_rearaxle(RWD)+... >torque=Te > >And then calculate rotational acceleration by torque/totalInertia >(taking into account the transmission's torque multiplier ofcourse). >Right? > >The differential will probably be the most problematic part, where I >have to model how it will allow both axle outputs to rotate (which >means the totalInertia might change if the diff locks up more or >less). > >This problem looks a lot like what I had once before, namely the >rotation of the wheels; what influence the drivetrain inertia has >together with the wheels on the total change of the engine's rpm. That >was mainly solved by just applying the torque and using the slip ratio >model. >But it seems strange to me what Gillespie writes, namely that torque >*decreases* as it moves from engine to the wheels. At least his >formula's imply so. > >Any thoughts? Thanks, > >Ruud van Gaal, GPL Rank +53.25 >Pencil art : http://www.marketgraph.nl/gallery/ >Car simulation: http://www.marketgraph.nl/gallery/racer/ Ruud,
I'll probably be needing your help with quaternions :0) Good luck on the
conversion.
It's strange how Gillespie's equations show a decrease in torque. I don't
have his book, so can't comment on that.
As far running the rotation stuff through the driveline goes, I use something
similar to what you posted:
>totalInertia=I_engine+I_driveshaft+I_transmission+I_rearaxle(RWD)+...
>torque=Te
>
>And then calculate rotational acceleration by torque/totalInertia
>(taking into account the transmission's torque multiplier ofcourse).
>Right?
That's how I do it. Not sure if it's right though :0)
>The differential will probably be the most problematic part, where I
>have to model how it will allow both axle outputs to rotate (which
>means the totalInertia might change if the diff locks up more or
>less).
>
Right now, I loosely simulate the differential action by assigning the drive
torques from the engine independently to each rear wheel, and letting them
accelerate on their own. This way, they're free to run at their own speeds.
It seems to work pretty well, as the inside tire spins first in a turn. By
matching the speeds to either the high or low speed tire, it works just like a
spool/locked rear end, exhibiting push and snap oversteer at high throttle.
Now, I need to know how the torques are supposed to really be applied, rather
than just splitting it 50/50 all the time.
Strange about Gillespie's stuff. Again, I haven't seen it so can't comment.
Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
Ruud van Gaal wrote:
>But it seems strange to me what Gillespie writes, namely that torque
>*decreases* as it moves from engine to the wheels. At least his
>formula's imply so.
>Any thoughts? Thanks,
Re-read Gillespie Chapter 2 and then sleep with it under your pillow ;)
The torque doesn't decrease, rathersome of it is expended to accelerate
the rotational inertia of the rotating parts. You have to expend
power to accelerate them up, and it also
takes more braking to slow them back down.
As the book explains, when accelerating the car, you are also
accelerating the rotating parts of the engine and the
drive train.
If you are accelerating a drag racing car at 3 G's with the
clutch not slipping and the final drive locked, you can
expend a noticible part of the engines torque production
just spinning up all this rotational inertia. This effect is most
noticible in the lowest gear, because when the clutch is
locked, the engine is accelerating very fast because
of the large gear ratios commonly in use.
As Gillespie notes, you can express the overall effect of
this as an "effective mass". This is through combining all the
rotational terms together, and noticing that they act just like
the mass in Forward_force = mass times acceleration
This becomes
acceleration = force / (mass + effective_mass_rotating_parts)
Where the effective mass can be several hundred pounds
if you aren't careful. Drag racers are careful, and do things like
using short aluminum or carbon drive shafts instead of long
steel ones, etc., to reduce this penalty. High tech road racers use
exotic wheel materials for similar reasons when allowed and
they can afford it.
The effective_mass of the rotational parts has terms like:
(inertia_wheels +
inertia_driveshaft * final_drive_ratio**2
inertia_engine * overall_gear_ratio**2) / tire_radius**2
given final drive ratios of 4-5 and overall first gear ratios of 12 or
more
you can see where those gear ratio squared terms can
get out of hand if not controlled.
To answer your question about how to get the accelerations,
"just" ;) solve the resulting equations for
the unknown accelerations.
It's messy but straightforward for each configuration of the driveline.
(Clutch slipping or not slipping, transmission in gear or out of gear,
differential locked or open = 8 or more cases! ;)
I use the Mathematica program to do this kind of algebra,
otherwise I'd be spending all my time correcting errors ;)
For your case with all nodes locked:
Te = point on the engine's torque curve
Tc = Te - Ie Ae
Tp = Gi Tc - Ip Ap p = pinion or driveshaft
Aw = (Gfd Tp - FxR) / Iw w = drive wheels,
FxR is the "Load" torque of the tires forward force
and noting:
Ae = Gi Gfd Aw,
Ap = Gfd Aw
Here is Mathematica script to solve this:
Ae = Gi Gfd Aw
Ap = Gfd Aw
Tc = Te - Ie Ae
Tp = Gi Tc - Ip Ap
(* then solve the combined equation below for Aw:
Aw = (Gfd Tp - FxR) / Iw
*)
Solve[{Aw == (Gfd Tp - FxR) / Iw}, {Aw}]
The solution is:
Aw = (-FxR + Gfd * Gi * Te) / (Gfd**2 * Gi**2 * Ie + Gfd**2 * Ip + Iw)
and the other accelerations easily derived from that.
(Gillespie gives essentially this solution in Chapter 2.)
Our games also include the transmission input shaft which adds some more
complexity but it is still straight forward but tedious without
Mathematica ;) Get Mathematica, particularly if you are a student.
They have student packages because it is more addictive than cigarettes!
;)
- Matt
P.S. Ruud, please note Very Important Caution interspersed below
Ruud van Gaal wrote:
Be very careful and do what Gillespie shows. Because of the different
gear ratios, the equation above is useless and misleading.
Use the form that includes consideration of the effect of the
differing rotational accelerations of each part.
The equation above can under estimate the effect of the
engine's inertia by a factor of 50 to 150 or more, depending on gear ratio
Quoted text (33 lines)
> Hi there, > > I'm adding some variables to my car model, while reading 'Fundamentals > of Vehicle Dynamics' from Thomas Gillespie. Well, actually, I'm > converting the body and wheels to rigid body classes which use > quaternions and inertia tensors for their rotation (so I have faster > functions and gyroscopic precession for free for all the > forces/torques I want to add) (this 'simplified' model will allow > easier inclusion of new forces/torques in a more clean way). > > Anyway, in the book, Gillespie follows the engine torque to the > wheels, and does it like this: > > Te=point on the engine's torque curve > Tc=Te-IeAe > where Tc=torque at the clutch, Ie=rotational inertia of the engine, > and Ae=engine rotational acceleration. > > Td=Tc-... > Ta=Td-... > > (Td=torque output to the driveshaft, Ta=torque on the axles) > > So he keeps subtracting torque in every step, based on the > acceleration. Now in simulation, the acceleration is *the question*, > rather than the answer to fill in the equations. It seems I can't use > these formula's like that. > It seems to me that since everything is fixed together, the torque > remains the same, but all inertia of all connected components must be > taken into account, so: > > totalInertia=I_engine+I_driveshaft+I_transmission+I_rearaxle(RWD)+...Quoted text (25 lines)
> torque=Te > > And then calculate rotational acceleration by torque/totalInertia > (taking into account the transmission's torque multiplier ofcourse). > Right? > > The differential will probably be the most problematic part, where I > have to model how it will allow both axle outputs to rotate (which > means the totalInertia might change if the diff locks up more or > less). > > This problem looks a lot like what I had once before, namely the > rotation of the wheels; what influence the drivetrain inertia has > together with the wheels on the total change of the engine's rpm. That > was mainly solved by just applying the torque and using the slip ratio > model. > But it seems strange to me what Gillespie writes, namely that torque > *decreases* as it moves from engine to the wheels. At least his > formula's imply so. > > Any thoughts? Thanks, > > Ruud van Gaal, GPL Rank +53.25 > Pencil art : http://www.marketgraph.nl/gallery/ > Car simulation: http://www.marketgraph.nl/gallery/racer/On Sat, 03 Feb 2001 04:26:17 GMT, "Matthew V. Jessick"
<[email hidden]> wrote:
>Ruud van Gaal wrote:
>>But it seems strange to me what Gillespie writes, namely that torque
>>*decreases* as it moves from engine to the wheels. At least his
>>formula's imply so.
>
>Re-read Gillespie Chapter 2 and then sleep with it under your pillow ;)
I will, if that will help! ;-)
...
>As Gillespie notes, you can express the overall effect of
>this as an "effective mass". This is through combining all the
>rotational terms together, and noticing that they act just like
>the mass in Forward_force = mass times acceleration
>This becomes
> acceleration = force / (mass + effective_mass_rotating_parts)
Yes, strange that mass and inertia can be interchanged like that. Like
E=mC^2. So this acceleration would be the linear acceleration of the
center of mass, right?
...
>The effective_mass of the rotational parts has terms like:
>
>(inertia_wheels +
> inertia_driveshaft * final_drive_ratio**2
> inertia_engine * overall_gear_ratio**2) / tire_radius**2
Yes, I've looked at this big formula multiple times. But I wondered
what would happen to it if one of the tires is off the ground, or
broken off (!), or getting light because of transverse
weight-shifting. It would seems that tire_radius (esp. when one of the
2 tires is broken off) will mislead the calculation, or not?
Or should I in the case of a missing wheel (broken off), remove 1
wheel of the 'inertia_wheels' variable? Sounds ok. But perhaps remove
a power from tire_radius as well?
((inertia_wheels+...)/tire_radius**(number_of_connected_wheels))
Thanks for the help, I've printed it and will reread it until I fully
understand it. :)
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Car simulation: http://www.marketgraph.nl/gallery/racer/
On 02 Feb 2001 23:59:00 GMT, [email hidden] (J. Todd Wasson) wrote:
> Ruud,
>
> I'll probably be needing your help with quaternions :0) Good luck on the
>conversion.
Thanks. I've done a little writing this morning. Now for a little time
off and back on it this evening. I'm basing things on Richard Chaney's
RigidBody class (www.chaney.karoo.net). This uses a linear
position/velocity, and a rotational position/velocity as the state for
a rigid body.
After that, he present formulas and source code to add torques and
forces (applied at body or world points) to the body, then moves on to
integrate, using either Euler or Runge-Kutta 4th order. All the
ingredients to make a new soup of things which will need some
debugging to get right. Fortunately, I have things working nicely as
it is with yaw/pitch/roll, so I just have to end up thereabouts again.
It also does precession. Funny is perhaps that linear/rotational
acceleration is not part of the body's state. That's only used when
applying forces/torques for a moment and in the RK integration.
I'm beginning to understand quats a little better step by step. They
have a funny origin, but are basically just rotations around a 3D
axis. Where the magic thing is that q1*q2 is both rotations
geometrically added, although I wouldn't know how to do this if just
given 2 axes and 2 angles. Nice things! Besides, they normalize very
quickly, because it's just a 4D vector. So rotation matrices won't
have squeezing problems.
I intend to convert the body first. The wheels, being so restricted,
are hardly free moving bodies. Although I wonder how big the effect of
gyroscopic precession is on turning if the wheels are spinning fast.
Perhaps its effect on Mx, the aligning moment, is greater than I think
(which is necessary ofcourse to in the end come up with great force
feedback).
It seems, reading Matt's reply, we can do better. Sure, ofcourse, this
is an endless field of optimizations and improvements! ;-)
...
> Right now, I loosely simulate the differential action by assigning the drive
>torques from the engine independently to each rear wheel, and letting them
>accelerate on their own. This way, they're free to run at their own speeds.
>It seems to work pretty well, as the inside tire spins first in a turn. By
>matching the speeds to either the high or low speed tire, it works just like a
>spool/locked rear end, exhibiting push and snap oversteer at high throttle.
You mean you take the speed of one of both tires, and apply its
rotational velocity to that of the *entire* axle? (making a solid
axle)?
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Car simulation: http://www.marketgraph.nl/gallery/racer/
Quoted text (11 lines)
> As far running the rotation stuff through the driveline goes, I use something >similar to what you posted: > >>totalInertia=I_engine+I_driveshaft+I_transmission+I_rearaxle(RWD)+... >>torque=Te >> >>And then calculate rotational acceleration by torque/totalInertia >>(taking into account the transmission's torque multiplier ofcourse). >>Right? > > That's how I do it. Not sure if it's right though :0)Quoted text (11 lines)
>totalInertia=I_engine+I_driveshaft+I_transmission+I_rearaxle(RWD)+... > >Be very careful and do what Gillespie shows. Because of the different >gear ratios, the equation above is useless and misleading. >Use the form that includes consideration of the effect of the >differing rotational accelerations of each part. >The equation above can under estimate the effect of the >engine's inertia by a factor of 50 to 150 or more, depending on gear ratio > > >Quoted text (13 lines)
>> Right now, I loosely simulate the differential action by assigning the >drive >>torques from the engine independently to each rear wheel, and letting them >>accelerate on their own. This way, they're free to run at their own speeds. > >>It seems to work pretty well, as the inside tire spins first in a turn. By >>matching the speeds to either the high or low speed tire, it works just like >a >>spool/locked rear end, exhibiting push and snap oversteer at high throttle. > >You mean you take the speed of one of both tires, and apply its >rotational velocity to that of the *entire* axle? (making a solid >axle)?
Ruud van Gaal wrote:
Yes. This is just a convenient collection of terms that
"acts like" more mass.
Yes, If the wheel isn't there, then spinning it up isn't going to
require torque ;)
--
Matthew V. Jessick Motorsims
[email hidden] http://www.motorsims.com
Vehicle Dynamics Engineer (972)910-8866 Ext.125, Fax: (972)910-8216
Quoted text (24 lines)
> > On Sat, 03 Feb 2001 04:26:17 GMT, "Matthew V. Jessick" > <[email hidden]> wrote: > > >Ruud van Gaal wrote: > >>But it seems strange to me what Gillespie writes, namely that torque > >>*decreases* as it moves from engine to the wheels. At least his > >>formula's imply so. > > > >Re-read Gillespie Chapter 2 and then sleep with it under your pillow ;) > > I will, if that will help! ;-) > > ... > >As Gillespie notes, you can express the overall effect of > >this as an "effective mass". This is through combining all the > >rotational terms together, and noticing that they act just like > >the mass in Forward_force = mass times acceleration > >This becomes > > acceleration = force / (mass + effective_mass_rotating_parts) > > Yes, strange that mass and inertia can be interchanged like that. Like > E=mC^2. So this acceleration would be the linear acceleration of the > center of mass, right?Quoted text (21 lines)
> > ... > >The effective_mass of the rotational parts has terms like: > > > >(inertia_wheels + > > inertia_driveshaft * final_drive_ratio**2 > > inertia_engine * overall_gear_ratio**2) / tire_radius**2 > > Yes, I've looked at this big formula multiple times. But I wondered > what would happen to it if one of the tires is off the ground, or > broken off (!), or getting light because of transverse > weight-shifting. It would seems that tire_radius (esp. when one of the > 2 tires is broken off) will mislead the calculation, or not? > > Or should I in the case of a missing wheel (broken off), remove 1 > wheel of the 'inertia_wheels' variable? Sounds ok. But perhaps remove > a power from tire_radius as well? > ((inertia_wheels+...)/tire_radius**(number_of_connected_wheels)) > > Thanks for the help, I've printed it and will reread it until I fully > understand it. :)
"J. Todd Wasson" wrote:
The particular equations tossed around previously in this thread
don't yet include efficiency terms. That's even more torque lost. ;)
(Although Gillespie Chapter 2 has some derivations
including them also.)
These equations just properly account for the different rotational
accelerations being experienced by the different rotating parts.
If the overall gear ratio is 12, the engine is accelerating
at 12 times the radians/sec/sec of the wheels.
So just adding the physical rotational inertias doesn't
account for the different accelerations the parts are experiencing.
Inertia * acceleration is larger for the faster elements
so you have to properly account for that when you combine
them to form an effective inertia (which you are going to
multiply by only one acceleration value).
If you want to use one "effective inertia" for the entire
locked together drive train, the terms combine so that
the gear ratio terms are actually squared. I can't think
of a good simple motivation for why it turns out that
way, other than the "cascade" of the equations:
Tc = Te - Ie Ae
Tp = Gi Tc - Ip Ap p = pinion shaft or drive shaft
... etc.
From just this part of it, with Ae = Gi Gfd Aw
and Ap = Gfd Aw
Tp = Gi (Te - Ie Gi Gfd Aw) - Ip Gfd Aw
so you can start to see how collecting the
inertia effects of several rotating parts geared in series
results in the proper "weighting" of the inertias
in calculating one effective inertia term for the
whole assemblage involves the square of the gear ratios
such as Gi Gi Ie above.
The reason it doesn't much matter for drag racing
is that it would be _too much_ if the
inertias weren't purposely made as light as possible.
A lot of the first gear time is also spent with
the clutch slipping so the engine acceleration
isn't involved. (The engine starts out at a high speed
and roughly stays there so it doesn't have to be
accelerated, at least until the clutch engages.)
I happen to be struggling against this effect at the moment
in some work I'm doing because I need to use higher
inertias than I should otherwise in order to avoid
numerical instabilities in the drive train.
Until we fix that next week, I've lost a couple
tenths of a second off my ET because of it.
--
Matthew V. Jessick Motorsims
[email hidden] http://www.motorsims.com
Vehicle Dynamics Engineer (972)910-8866 Ext.125, Fax: (972)910-8216
Quoted text (19 lines)
> > >totalInertia=I_engine+I_driveshaft+I_transmission+I_rearaxle(RWD)+... > > > >Be very careful and do what Gillespie shows. Because of the different > >gear ratios, the equation above is useless and misleading. > >Use the form that includes consideration of the effect of the > >differing rotational accelerations of each part. > >The equation above can under estimate the effect of the > >engine's inertia by a factor of 50 to 150 or more, depending on gear ratio > > > > > > > > Yikes! I better get Gillespie's book too, as I must be doing this > incorrectly. There's been a long, long series of debates in the past (in other > forums) on mechanical efficiency through a drivetrain. Engineer types usually > insist it's around 95% or better, while drag racing folks insist it's usually > from 75-90% or so. This changes with engine torque of course, so in my drag > racing predictor, I allow people to input a "torque lost to friction" value.
"J. Todd Wasson" wrote:
> BTW, what's the name of Gillespie's book ?
"Fundamentals of Vehicle Dynamics," Thomas Gillespie,
SAE, Danvers, MA, 1992. ISBN 1-56091-199-9
It's an excellant basic book. His primary field of
expertise is in vibrations I believe, so besides
being good for basic vehicle dynamics, it also
covers vibrations. The appendices include the
SAE J607e recommended practice for vehicle dynamics
terminology and the SAE J6a Ride and Vibration Data Manual
so it is a convenient way to get those as well.
--
Matthew V. Jessick Motorsims
[email hidden] http://www.motorsims.com
Vehicle Dynamics Engineer (972)910-8866 Ext.125, Fax: (972)910-8216
Thanks, Matt. I'll look into it.
Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
On 03 Feb 2001 17:40:08 GMT, [email hidden] (J. Todd Wasson) wrote:
While I haven't measured power losses through drag racing gearboxes
(or differentials), I can understand why "engineer types" don't agree
with efficiencies of 75-90%. Just look at the heat generation values
implied with low efficiencies like this. While this might not be a
significant factor in the short time frame of drag racing, think about
for a longer race where steady state values are reached. Using an
*average* horsepower of 500 bhp = 373 kW, an efficiency of 75% tells
you that the heat rejection is 25% of 373 kW, or 93 kW. There is no
way that amount of heat is being rejected in a racing gearbox!
Quoted text (18 lines)
>>totalInertia=I_engine+I_driveshaft+I_transmission+I_rearaxle(RWD)+... >> >>Be very careful and do what Gillespie shows. Because of the different >>gear ratios, the equation above is useless and misleading. >>Use the form that includes consideration of the effect of the >>differing rotational accelerations of each part. >>The equation above can under estimate the effect of the >>engine's inertia by a factor of 50 to 150 or more, depending on gear ratio >> >> >> > > Yikes! I better get Gillespie's book too, as I must be doing this >incorrectly. There's been a long, long series of debates in the past (in other >forums) on mechanical efficiency through a drivetrain. Engineer types usually >insist it's around 95% or better, while drag racing folks insist it's usually >from 75-90% or so. This changes with engine torque of course, so in my drag >racing predictor, I allow people to input a "torque lost to friction" value.Quoted text (12 lines)
>The results have been excellent in terms of prediction accuracy, but perhaps >I'm merely understating the rotational inertia effect as you pointed out. Any >thoughts, Matt? This program will be needing a complete re-write after my 3-D >physics engine is done. > > >Todd Wasson >--- >Performance Simulations >Drag Racing and Top Speed Prediction >Software >http://PerformanceSimulations.ComQuoted text (9 lines)
>While I haven't measured power losses through drag racing gearboxes >(or differentials), I can understand why "engineer types" don't agree >with efficiencies of 75-90%. Just look at the heat generation values >implied with low efficiencies like this. While this might not be a >significant factor in the short time frame of drag racing, think about >for a longer race where steady state values are reached. Using an >*average* horsepower of 500 bhp = 373 kW, an efficiency of 75% tells >you that the heat rejection is 25% of 373 kW, or 93 kW. There is no >way that amount of heat is being rejected in a racing gearbox!On Sat, 03 Feb 2001 04:26:17 GMT, "Matthew V. Jessick"
<[email hidden]> wrote:
...
>The effective_mass of the rotational parts has terms like:
>
>(inertia_wheels +
> inertia_driveshaft * final_drive_ratio**2
> inertia_engine * overall_gear_ratio**2) / tire_radius**2...
>To answer your question about how to get the accelerations,
>"just" ;) solve the resulting equations for
>the unknown accelerations....
>Aw = (Gfd Tp - FxR) / Iw w = drive wheels,
> FxR is the "Load" torque of the tires forward force...
>The solution is:
>Aw = (-FxR + Gfd * Gi * Te) / (Gfd**2 * Gi**2 * Ie + Gfd**2 * Ip + Iw)
That's where my problem still is, I can get to the Aw=... formula, but
FxR is an unknown variable in my head too. :) (making 2 unknown var's,
1 equation, deadlock)
Ok, so R = radius of the wheel.
Fx is then just the last (longitudinal) force that was calculated the
last 'frame' (derived from the slipRatio graph)?
>Our games also include the transmission input shaft which adds some more
>complexity but it is still straight forward but tedious without
>Mathematica ;) Get Mathematica, particularly if you are a student.
I'll keep this in mind. Thanks for the tip. :)
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Car simulation: http://www.marketgraph.nl/gallery/racer/
On 03 Feb 2001 17:40:08 GMT, [email hidden] (J. Todd Wasson) wrote:
>>totalInertia=I_engine+I_driveshaft+I_transmission+I_rearaxle(RWD)+...
>>
>>Be very careful and do what Gillespie shows. Because of the different
>>gear ratios, the equation above is useless and misleading....
> Yikes! I better get Gillespie's book too, as I must be doing this
>incorrectly.
Perhaps it's not so bad. If you multiply the inertia mentioned by the
appropriate gear ratios (depending on where the inertia 'are' in the
engine; in front of the transmission or behind it, and in front of or
behind the final drive ratio), then I'd say it's not that bad. If not
correct. ;-)
The are also some efficiencies associated with these numbers as well
in Gillespie's book. Which are in the range of 97%-99% mainly though.
But still, I've always found my Ferrari (virtual!) to spin up a bit
too quickly.
The quaternion code works btw. :) Cost me a whole day to find a bug
where I mixed up 1 line of world & body coordinates, sigh, but voila.
Now to throw the car into the air and see how it rotates with
precession. That shouldn't be hard, given my driving style. ;-)
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Car simulation: http://www.marketgraph.nl/gallery/racer/
A large part of the losses in the whole system can probably be
attributed to the slip ratio not being zero. The loss percentage is
roughly the same as the value of the slip ratio.
My guess, however, is that your simulation already takes slip ratios
into account, and such losses are taken care of automatically if it's
done this way.
-Gregor
"J. Todd Wasson" wrote:
Quoted text (31 lines)
> > Right! This is what I don't understand. In writing SAS (in my link below), > I read lots of debates on this subject and still don't have a clear answer on > what's really going on there. Patrick Hale, creator of Quarter and Quarter Jr, > the pioneer in this field, appears to be the only one using efficiency values > in the 95+% range in his software. Since it's listed as "transmission > efficiency", perhaps he's got another efficiency for the rest of the drivetrain > already built into his software. > > For some reason, when I use values that are unrealistic to engineers > (75%-90%), I come up with almost exactly the same outputs as Mr. Hale's > programs do. I'm hoping that Ruud Van Gaal's book observations and Matt > Jessick's explanations will shed some light on this subject for once :0) I > suspect that I, along with several other developers of drag racing predictors, > may be miscalculating the torque required to accelerate the drivetrain. Who > knows? I'll have to get Gillespie's book and do some studying. > > On the other hand though, the high performance car and drag race magazines > and racers seem to agree that the driveline efficiency is indeed this poor, > regardless of what anybody says about the incredible heat that "should" be > generated. The main thing right now that makes me suspect the lower values are > true is that my top speed predictions remain far more accurate with the low > efficiency numbers racers and dyno testers swear by, even though they should be > generating enough heat to do quite a bit of damage, from what others say. > > Todd Wasson > --- > Performance Simulations > Drag Racing and Top Speed Prediction > Software > http://PerformanceSimulations.ComQuoted text (8 lines)
>> Yikes! I better get Gillespie's book too, as I must be doing this >>incorrectly. > >Perhaps it's not so bad. If you multiply the inertia mentioned by the >appropriate gear ratios (depending on where the inertia 'are' in the >engine; in front of the transmission or behind it, and in front of or >behind the final drive ratio), then I'd say it's not that bad. If not >correct. ;-)>A large part of the losses in the whole system can probably be
>attributed to the slip ratio not being zero. The loss percentage is
>roughly the same as the value of the slip ratio.
>
Well, what I'm really referring to here is the ratio of torque output at the
flywheel to the rear wheels (or is it the other way around?? :0) ) SAS doesn't
use slip ratios because I didn't understand them when I wrote it. It still
makes good predictions, but the final rpm will be off a few percent because the
slip ratio is locked to 0 (coulomb friction model.) It calculates the
traction limit and doesn't allow the force to exceed it, kind of like traction
control. It'll still tell you what speed range to expect wheelspin, but it
controls it.
When running my 3-D project, I get performance that matches up really closely
to SAS predictions, even with the slip ratio included, so it appears to not
really be a factor. The losses I'm talking about are frictional through the
drivetrain. In drag racing circles, folks are always talking about "rear wheel
vs. flywheel horsepower," and looking for quick answers to the percentage
difference. Anyway, I could go on and on about this, but to make a long story
short, on one side I find engineering folks arguing that 70-90% efficiency
would cause far too much heat and is therefore impossible. But on the other
side are the dyno test guys that seem to prove them wrong time and again.
Well, I've covered this in another post, so I won't go further :0)
It's still a bit of a mystery that I'd love to be able to prove one way or
the other, and finally dispel the myth that one side or the other believes once
and for all :0) Geeze, I need a life..... :-P
Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
Ruud van Gaal wrote:
For real time use, that may be what you have to do.
However it adds some lag into the system that
can hurt the numerical stability.
You need to be very careful about the radius also,
if you allow it to change. If you do, this can create
another high frequency dynamical "vibration" mode in
the overall system that can interact with the longitudinal
dynamics that interacts with the suspension dynamics that
upsets the ...;)
--
Matthew V. Jessick Motorsims
[email hidden] http://www.motorsims.com
Vehicle Dynamics Engineer (972)910-8866 Ext.125, Fax: (972)910-8216
Quoted text (7 lines)
> That's where my problem still is, I can get to the Aw=... formula, but > FxR is an unknown variable in my head too. :) (making 2 unknown var's, > 1 equation, deadlock) > > Ok, so R = radius of the wheel. > Fx is then just the last (longitudinal) force that was calculated the > last 'frame' (derived from the slipRatio graph)?On 07 Feb 2001 06:16:56 GMT, [email hidden] (J. Todd Wasson) wrote:
>>Yes, but notice, as Matt explained in a previous post, that the
>>inertia is affected by the squared gear ratio, it seems....
> Ruud, I just got home and am a slightly intoxicated right now and need sleep,
>but I think I figured out exactly how and why this works the way it does while
>wandering aimlessly around at work today. Not sure if I want to share this
>though!! lol
Hehe, that makes me all the more curious!
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Car simulation: http://www.marketgraph.nl/gallery/racer/
"J. Todd Wasson" wrote:
> I think it might be correct, as Gillespie's formulas are dealing with an
> "effective mass increase", to simulate the rotational inertia effects, right?
Just write Simulate with a capital S. ;)
The effective mass is just some of the terms of the rotational
equations of motion collected together. When this is done,
together they end up looking like a mass.
> If so, I think I might have it down ok. In a creative flash, I got an idea how
> to do it with all the sections operating at different speeds and input/output
> torques and think it works fine. I end up making a big term that is the
> "equivalent polar moment of inertia", which changes with each gear.
This is exactly what those equations do. They collect terms such that
you can divide one torque by that effective inertia to find one
angular acceleration (for a chosen one of the rotating pieces that
are geared together.) You can them find the other accelerations
using the gear ratios between the pieces.
- Matt
Ruud van Gaal wrote:
The normal force is involved, because it affects the F force of the F cross R
> >You need to be very careful about the radius also,
> >if you allow it to change.
>
> You mean like a loaded_Radius? Currently I leave the radius as it is.
Yes, probably for the best ;)
- Matt
Quoted text (20 lines)
> On Tue, 06 Feb 2001 00:47:46 GMT, mjessick-Motorsims > <[email hidden]> wrote: > > > > > > >Ruud van Gaal wrote: > >> That's where my problem still is, I can get to the Aw=... formula, but > >> FxR is an unknown variable in my head too. :) (making 2 unknown var's, > >> 1 equation, deadlock) > >> > >> Ok, so R = radius of the wheel. > >> Fx is then just the last (longitudinal) force that was calculated the > >> last 'frame' (derived from the slipRatio graph)? > > > >For real time use, that may be what you have to do. > > Hm, I'll rethink the equations then. Strange then that the load force > (the weight on the tire) isn't in the Aw formula? You would say this > has an effect on the acceleration of the wheel. >Quoted text (9 lines)
>> Ruud, I just got home and am a slightly intoxicated right now and need >sleep, >>but I think I figured out exactly how and why this works the way it does >while >>wandering aimlessly around at work today. Not sure if I want to share this >>though!! lol > >Hehe, that makes me all the more curious! >Quoted text (13 lines)
>Perhaps the dropdown in torque goes somewhere else? Perhaps it is in >the squared ratio vs. linear ratio weighing of the inertia of the >driveline components. >If you're calculating the driveline inertia (the plural of inertia is >just 'inertia', right?) by simple multiplying: >Iengine=Nfd*Ng*Iengine >then you're probably underestimating the inertia by quite some >factors, according to Gillespie and Matt. If so, you'd need a lower >efficiency number which would make up for the underestimation. >Ofcourse, this would be a real 'how could it ever have worked!' type >of bug, but perhaps it is, and after doing the inertia right, you'll >come up with needing far higher efficiencies. >Quoted text (7 lines)
>Yes, and I wasn't feeling good as well (a little flu). Or am I mixing >up action and reaction? ;-) >I've found that almost all major bugs consist of really 1 little flaw >somewhere in the system. Like doing += instead of -=. Endless >scribbling of numbers on papers, seeing where the numbers go wrong, >sigh, and that with suspensions, gravity and other forces making >estimations of what's right and what's not very hard.Quoted text (7 lines)
>I have some problems now that I don't have pitch/yaw/roll angles >anymore (for the camera view; I don't know anymore how to follow the >car correctly so that I'm always behind it). On the other hand, all >trigonometry is disappearing! No sin(), cos() or tan(); it's all >one-time setup of a start quaternion, and after that you don't need >more than a handful of * and + to rotate about axes. Strange, but >wonderful. :)Quoted text (7 lines)
>>When you toss the car, compare it to my vector3b.exe program and let me know >of >>any obvious differences, if you'd be so kind :0) > >I will. The three values in your .exe are the inertia values of XYZ? > >Perhaps. I'll try the equations from my other post in the 3-D model, since
it gets the same results as SAS, and see what happens. This just might be
where folks are getting confused. If so, the issue of "correct efficiencies"
can be put to rest in the drag racing community once and for all :0) Won't
that be fun to debate with people?
You're telling me??? lol I feel ya on this one!
When you switched to quarternions, right?
It's a huge relief when you fix something like that. Makes you want to break
stuff, doesn't it? :0)
Yes, I've been thinking about that using the 3x3 matrix and inertia tensor.
It'll be a relief for sure, and will probably make the rest of everything much
simpler.
This one I haven't figured out yet. If you've got a spinning wheel attached
to the car and you turn it, how do you calculate the torques sent to the car?
Do you find the 3 axis (world) angular momentum change and apply that to the
body? If so, that'd be pretty cool. Just like GPL :0)
Yes. Z is about the axis pointing into the screen, x is left/right and y is
up/down. The matrix doesn't reorthagonalize itself, so if you spin it fast,
it'll go crazy and squash itself. Just try slow rotation and let me know how
it compares.
Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
>Just write Simulate with a capital S. ;)
I sure do like that word, don't I? :0)
Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
By the way, that stuff would give you the rotational acceleration of the
engine if you set i1 to be inertia of the engine, then go on down the
drivetrain with as many rotating parts as you want to use. You still need to
apply torque to this from the slip ratio (the old "fighting the engine" stuff
from months ago). I think this would be the product of all the gear ratios (in
reverse order, or inverted (1/whatever)) and the torque at the wheels. This
would be added to engine torque, divided by the "effective inertia" from the
other post, and used to accelerate *body 1*, and that's it. The rest of the
velocities could obviously be calculated by multiplying engine speed by the
appropriate gear ratios.
Hmm... Maybe we shouldn't be talking about this stuff in a widely read
newsgroup ? :-)
This has got me excited. It ought to be not too terribly difficult to do a
four wheel drive system that actually works the way it should. Too bad I don't
know much about differentials yet :0P
Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
On Thu, 08 Feb 2001 06:23:06 GMT, "Matthew V. Jessick"
<[email hidden]> wrote:
Polar is angular, right? So polar moment of inertia means rotational
inertia, right?
Ok, anyway, I did a derivation yesterday night which I'll put up more
expandedly on my site this weekend probably (I have to run now to get
some deadlines done!), based on Gillespie's equations, but working out
all accelerations, since I want to know about torque, and derive
accelerations from that.
In the end, I get:
Tw=(C2*Iw)/(C1+Iw)
Where Tw is torque at the wheels/rear axle, Iw is the combined inertia
of rear axles and (connected) wheels. You start out with Te (engine
torque, from a curve). C2 and C1 are constants where:
C1=Ie*Ntf**2-ItNtf**2-IdNf**2
C2=TeNtf
Where:
Ie=engine inertia
Nt=transmission ratio (gear ratio)
Nf=final gear ratio
Ntf=Nt*Nf
Id=inertia of driveshaft
It=inertia of transmission
After moving down all equations tucked into eachother. It's without
the FxR term, because I just go from:
Te=engine torque
Tw=.... (see above)
Then apply the torque at the wheels, minus the road reaction force,
minus the braking force.
As for efficiencies; it's strange, I reread a part where he stated
80%-90% efficiencies, but then in an example continues to use 97%+.
Incorporating efficiences in the above? Hm, might be done as
Ie=.97*Ie, something like that (C1=eff_Ie*Ie*Ntf**2...)
Ok, have to hurry now, talk to you guys later,
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Car simulation: http://www.marketgraph.nl/gallery/racer/
Quoted text (10 lines)
>> If so, I think I might have it down ok. In a creative flash, I got an idea how >> to do it with all the sections operating at different speeds and input/output >> torques and think it works fine. I end up making a big term that is the >> "equivalent polar moment of inertia", which changes with each gear. > >This is exactly what those equations do. They collect terms such that >you can divide one torque by that effective inertia to find one >angular acceleration (for a chosen one of the rotating pieces that >are geared together.) You can them find the other accelerations >using the gear ratios between the pieces.Quoted text (25 lines)
>Now the fun part. What about a third body at the end of the line, with >another gear? As before, we could set an effective moment of inertia for >each >body, then add them up. The third body would have GearRatio set according to >the joint between it and the second body. However, it's input torque will be >drastically different because it's changed at the first and the second >(sequentially arranged) gears. I'd set the input torque by multiplying by >the >first gear ratio, then use the equation above in addition to it. The third >body's effective inertia becomes: > > Ei3 = GearRatio1 * (1/GearRatio2^2) * i3 > > The second body is: > > Ei2 = 1/(GearRatio^2) * i2 > > The first body is just i1. Total? > > EiTotal = i1 + Ei2 + Ei3 > > or, in long terms: > > EiTotal = i1 + 1/(GearRatio1^2) * i2 + GearRatio1 * (1/GearRatio2^2) * i3 >On 08 Feb 2001 07:06:39 GMT, [email hidden] (J. Todd Wasson) wrote:
> For two bodies, define an effective inertia for each one.
Etc. This has been a while ago, but I recently did some figuring out
of effective inertia's for geared components and finally put up a
small article on it on my page:
http://www.marketgraph.nl/gallery/racer/tech/effinertia.htm
You can get there from the normal Racer page as well through
'Programmer info' and selecting the article from there, but ofcourse a
direct link is easier.
Feel free to shoot at it! But I hope to clarify where all the squared
terms come from (taking a different perspective) in Gillespie's
equations to calculate one big effective inertia for geared
components, and provide a method to check whether your formula is
correct for any gearing combination by using an energy approach.
I hope it's correct, but if you find errors, please let me know so I
can correct them (or remove the file altogether if it turns out to be
all a bunch of crap ;-)).
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Free car sim : http://www.marketgraph.nl/gallery/racer/
Hi Ruud :)
There are already some Sims with effective inertia build into physical model
code,
specifically at the centripedal forces.
Best
Miguel Romao
Ruud van Gaal <[email hidden]> escreveu na mensagem
news:[email hidden]...
Quoted text (28 lines)
> On 08 Feb 2001 07:06:39 GMT, [email hidden] (J. Todd Wasson) wrote: > > > For two bodies, define an effective inertia for each one. > > Etc. This has been a while ago, but I recently did some figuring out > of effective inertia's for geared components and finally put up a > small article on it on my page: > > http://www.marketgraph.nl/gallery/racer/tech/effinertia.htm > > You can get there from the normal Racer page as well through > 'Programmer info' and selecting the article from there, but ofcourse a > direct link is easier. > > Feel free to shoot at it! But I hope to clarify where all the squared > terms come from (taking a different perspective) in Gillespie's > equations to calculate one big effective inertia for geared > components, and provide a method to check whether your formula is > correct for any gearing combination by using an energy approach. > > I hope it's correct, but if you find errors, please let me know so I > can correct them (or remove the file altogether if it turns out to be > all a bunch of crap ;-)). > > > Ruud van Gaal, GPL Rank +53.25 > Pencil art : http://www.marketgraph.nl/gallery/ > Free car sim : http://www.marketgraph.nl/gallery/racer/On Mon, 18 Jun 2001 18:21:57 +0100, "LB" <[email hidden]> wrote:
>Hi Ruud :)
>There are already some Sims with effective inertia build into physical model
>code,
>specifically at the centripedal forces.
I hope so. :) But a lot of us here are implementing their own physics
code, either because of library code licensing issues, or just we all
want to do it our own way. ;-)
Cheers,
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Free car sim : http://www.marketgraph.nl/gallery/racer/
Funny coincendence, I just downloaded that yesterday from your site to see if
you'd updated it yet :-) Will check now.
Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
On 18 Jun 2001 21:51:45 GMT, [email hidden] (J. Todd Wasson) wrote:
> Funny coincendence, I just downloaded that yesterday from your site to see if
>you'd updated it yet :-) Will check now.
Great timing. :)
There's also a new little chat about track splines, which I put up a
few hours after the inertia document. The track splines are now
working, and I'm trying to get a renewed look at the Oval, with
splines and with a horizon now...
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Free car sim : http://www.marketgraph.nl/gallery/racer/
I read about the splines too. Very interesting. I'm currently modelling
bumps using a similar method. I'd like to learn more.
Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
Ruud,
I have managed to get combined slip to work (at least theoretically). I got
a bit confused with Brian's stuff and ended up using G.Genta's
"intermediate" solution.
Have a look at my lovely graphs (under physics) -
http://sim.twistedtech.co.uk
All the best
Ash
Quoted text (8 lines)
| Now where was that printout from Brain Beckman's 'Combined Pacjeka | Longitudinal and Lateral' again. Still haven't read it. Might give | some more clues as to why the car's too touchy. | | | Ruud van Gaal, GPL Rank +53.25 | Pencil art : http://www.marketgraph.nl/gallery/ | Free car sim : http://www.marketgraph.nl/gallery/racer/On 20 Jun 2001 03:58:40 GMT, [email hidden] (J. Todd Wasson) wrote:
> I read about the splines too. Very interesting. I'm currently modelling
>bumps using a similar method. I'd like to learn more.
I'll have to visualize the splines; I drove an oval with splines
yesterday and it's better, but in the corners it has some modulation
at the wheel, some jittering, which may be due to the difference in
the 2 triangles. Still, a lot better than WITHOUT splines. :)
And somehow the shadow intersections go bad; perhaps the two problems
are interrelated.
I'll just go for locking diffs and some other physics now, the splines
are ok for the moment, and the car needs working, since it spins out
much too easily and for too long (combined lat+lon forces @#!@#$).
Now where was that printout from Brain Beckman's 'Combined Pacjeka
Longitudinal and Lateral' again. Still haven't read it. Might give
some more clues as to why the car's too touchy.
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Free car sim : http://www.marketgraph.nl/gallery/racer/
Hi Ruud,
I just read the inertia stuff; great work, I wish I had the energy to
write stuff down in such an easy to understand manner. :)
There might not be much wrong with your physics model regarding the
ability of the car to spin. With my model, I've found that I need to
very carefully ballance the tyre specifications to create a well
handling car; I mentioned this in another thread a while ago, noting
that once you have a good physics engine, you then need to become an
engineer to sort a proper handling car from it. The first thing to do is
to readjust the front to rear tyre grip ratio (that is, if the tyre
specs are different rear to front in the first place). The next place to
look is softening the rear suspension, as this can create miracles (or
disasters ;) ) as well. I'm still struggling to create a car that will
point nice and straight at low speeds, but not create too much
understeer at high speeds without putting in too much front wing.
What I want to say is, maybe your tyre model is just fine, but the car
itself needs tuning.
-Gregor
Ruud van Gaal wrote:
Quoted text (19 lines)
> > I'll have to visualize the splines; I drove an oval with splines > yesterday and it's better, but in the corners it has some modulation > at the wheel, some jittering, which may be due to the difference in > the 2 triangles. Still, a lot better than WITHOUT splines. :) > And somehow the shadow intersections go bad; perhaps the two problems > are interrelated. > > I'll just go for locking diffs and some other physics now, the splines > are ok for the moment, and the car needs working, since it spins out > much too easily and for too long (combined lat+lon forces @#!@#$). > > Now where was that printout from Brain Beckman's 'Combined Pacjeka > Longitudinal and Lateral' again. Still haven't read it. Might give > some more clues as to why the car's too touchy. > > Ruud van Gaal, GPL Rank +53.25 > Pencil art : http://www.marketgraph.nl/gallery/ > Free car sim : http://www.marketgraph.nl/gallery/racer/On Wed, 20 Jun 2001 11:04:36 +0100, "Ashley McConnell"
<[email hidden]> wrote:
>Ruud,
>
>I have managed to get combined slip to work (at least theoretically). I got
>a bit confused with Brian's stuff and ended up using G.Genta's
>"intermediate" solution.
The graphs look good; I must say it looks the same as my graphs here
(using the Ferrari Pacejka constants; I have a Pacejka Player thing by
now but it's so crappy that I won't release it yet hehe). With the
intermediate solution you mean taking the square root and making the
lateral force less important than the longitudinal force?
I use the extract below, but I have a very slippery car once it is
thrown sideways. Slides on much too long. I'll have to check if I
don't have a jittering longitudinal force which takes away too much of
the lateral force that can be generated.
I'll see if I can understand Brian's thoughts. He often takes a rather
different approach. :)
Ruud
--- rwheel.cpp extract
// From G. Genta's 'Motor Vehicle Dynamics', page 83, eq. 2.24
// (Fy/Fy0)^2+(Fx/Fx0)^2=1
// Where Fy0 is the lateral force calculated using Pacejka, but
// without taking into account any longitudinal force,
// and Fx0 is the MAXIMUM longitudinal force. Fx is calculated
// using Pacejka, and Fy is the unknown variable
// Rewriting results in: Fy=Fy0*sqrt(1-(Fx/Fx0)^2)
maxForce=pacejka.GetMaxLongForce();
// Adjust maximum force for current friction coefficient
// (based on slipvel)
maxForce*=frictionCoeff;
if(maxForce>D3_EPSILON)
{
dfloat Fy,Fy0,Fx,Fx0,ratioSquared;
Fy0=pacejka.GetFy();
Fx0=pacejka.GetMaxLongForce();
Fx=pacejka.GetFx();
ratioSquared=Fx/Fx0;
ratioSquared*=ratioSquared;
Fy=Fy0*sqrtf(1.0f-ratioSquared);
//qdbg("Flat FC'ed from %f to %f\n",Fy0,Fy);
forceRoadTC.x=Fy;
}
>
>Have a look at my lovely graphs (under physics) -
>http://sim.twistedtech.co.uk
>
>All the best
>Ash
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Free car sim : http://www.marketgraph.nl/gallery/racer/
On Wed, 20 Jun 2001 11:04:36 +0100, "Ashley McConnell"
<[email hidden]> wrote:
By the way, the rolling resistance seems to go up quite a bit, this
might be ok but for future enhancements, I read in John Dixon's book
that rolling resistance keeps quite low but at a certain turning point
you get waves in your tire that go out of hand and make for a suddenly
much higher rolling resistance. That's why some tires are not allowed
to be driven above x km/h. Like the fast/slow bump/rebound of dampers
a bit.
Ah well, future ideas, we all have virtual tires good up to 400 km/h
ofcourse. :)
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 (8 lines)
>Ruud, > >I have managed to get combined slip to work (at least theoretically). I got >a bit confused with Brian's stuff and ended up using G.Genta's >"intermediate" solution. > >Have a look at my lovely graphs (under physics) - >http://sim.twistedtech.co.ukHi Gregor,
>I just read the inertia stuff; great work, I wish I had the energy to
>write stuff down in such an easy to understand manner. :)
Thanks. :)
>There might not be much wrong with your physics model regarding the
>ability of the car to spin. With my model, I've found that I need to
>very carefully ballance the tyre specifications to create a well
>handling car; I mentioned this in another thread a while ago, noting
>that once you have a good physics engine, you then need to become an
>engineer to sort a proper handling car from it.
Yes, yikes! ;-)
>The first thing to do is
>to readjust the front to rear tyre grip ratio (that is, if the tyre
>specs are different rear to front in the first place). The next place to
>look is softening the rear suspension, as this can create miracles (or
>disasters ;) ) as well.
I will try this. After driving at the oval yesterday I also realise I
will probably have to do that steering ratio thing; steer less when
speed is high.
How would you rate the influence of a (partially) locking differential
at the rear? With the open version that you had before, it seems the
wheel rpm differences can go up quite a bit quickly, so locking might
make things a lot more stable.
> I'm still struggling to create a car that will
>point nice and straight at low speeds, but not create too much
>understeer at high speeds without putting in too much front wing.
Yes, some wings, I haven't got those yet, but will attempt to get a
simple version in. Todd recently pointed my to FoilSim:
http://www.grc.nasa.gov/WWW/K-12/aerosim/
Which allows you to play around with wings.
>What I want to say is, maybe your tyre model is just fine, but the car
>itself needs tuning.
Yes, definitely. :) But I'm a little hesitant on doing too much
setting up, as I'm still lacking the differential locking. I think
wings will only make me go faster without losing control, and rolling
resistance, well. And ofcourse the anti-roll bar, also seems to be
important. Enough with the splines, on to the physics again! :)
PS That BridgeBuilder game is really fabulously addictive! :) Sad too
see it ate all the attention away from the free sim though, lol.
Cheers,
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Free car sim : http://www.marketgraph.nl/gallery/racer/
Hi Ruud!
Ruud van Gaal wrote:
>
> I will try this. After driving at the oval yesterday I also realise I
> will probably have to do that steering ratio thing; steer less when
> speed is high.
>
Just be sure that the higher steering ratio should apply only to very
low speeds (i.e. parking maneuvers), and then turns itself off at higher
speeds, as otherwise this can ruin the feel for the car.
>
> How would you rate the influence of a (partially) locking differential
> at the rear? With the open version that you had before, it seems the
> wheel rpm differences can go up quite a bit quickly, so locking might
> make things a lot more stable.
>
Definitely. I am using a viscous type of a differential and indeed it
has a profound stability effect. In principle, the more locked the diff,
the more understeering the car will be in the normal operating regime,
but the power oversteer becomes much more snappy that way.
>
> Yes, some wings, I haven't got those yet, but will attempt to get a
> simple version in. Todd recently pointed my to FoilSim:
> http://www.grc.nasa.gov/WWW/K-12/aerosim/
> Which allows you to play around with wings.
>
It's great to see how wings work, but one should be aware of the
limitations. Since I would imagine that the wings on a car rarely
operate close to stall angles, the whole applet could be quite accurate,
but the effects of finite size wings and/or endplates should also be
taken into account, as these can be dramatic. At this point, I
personally would go with empirical estimates.
Yes, wings shouldn't be a priority at this stage. If anything, they make
a car harder to control close to the limit. Antiroll bars, well, there's
something I still need to implement :) .
Now, a question for the more knowledgeable; I heard a few times that
highly aero dependant cars may not use anti roll bars, but a mechanism
quite opposite to it (softer in differential action than collective,
which is achieved by a special arrangement of springs). Is this really
so?
>
> PS That BridgeBuilder game is really fabulously addictive! :) Sad too
> see it ate all the attention away from the free sim though, lol.
>
It sure is :).
Cheers,
-Gregor
Quoted text (10 lines)
> > >What I want to say is, maybe your tyre model is just fine, but the car > >itself needs tuning. > > Yes, definitely. :) But I'm a little hesitant on doing too much > setting up, as I'm still lacking the differential locking. I think > wings will only make me go faster without losing control, and rolling > resistance, well. And ofcourse the anti-roll bar, also seems to be > important. Enough with the splines, on to the physics again! :) >
On Wed, 20 Jun 2001, Gregor Veble wrote:
> Now, a question for the more knowledgeable; I heard a few times that
> highly aero dependant cars may not use anti roll bars, but a mechanism
> quite opposite to it (softer in differential action than collective,
> which is achieved by a special arrangement of springs). Is this really
> so?
If we are talking about the same thing then these are often called "third
spring" systems, fitted iirc on F1, CART and probably other cars. The
third spring pushes equally on both wheels on one end of the car (through
some kind of balance-beam mechanism); another configuration is the Z-bar
(or pivoted leaf-spring "camber compensator") which does the same kind of
thing.
Since there is also an anti-roll bar fitted on many of these cars, there
are really 4 springs for 2 wheels! The two original ride springs could be
removed and things would still work with just the "third spring" for ride
and the anti-roll bar for roll.
On race cars, a bump stop with "packers" (adjusting shims) is always fitted
on the third spring and this will control the _average_ minimum ride height
for the two wheels. Note that F1 cars have a plank down the center of the
car that must be kept off the road, and the original purpose of the "third
spring" becomes clear -- you can set packers (a bump stop) that controls
the height of the plank, regardless of the roll angle of the body.
-- Doug
Douglas Milliken <[email hidden]>
Milliken Research Associates Inc.
Hello Doug!
Springy things, those cars, aren't they ;). Thanks for the reply, this
is most likely what I had in mind. Now, give me a couple of days to
study this to really get a good picture of what the system looks like
:).
-Gregor
Doug Milliken wrote:
Quoted text (23 lines)
> > If we are talking about the same thing then these are often called "third > spring" systems, fitted iirc on F1, CART and probably other cars. The > third spring pushes equally on both wheels on one end of the car (through > some kind of balance-beam mechanism); another configuration is the Z-bar > (or pivoted leaf-spring "camber compensator") which does the same kind of > thing. > > Since there is also an anti-roll bar fitted on many of these cars, there > are really 4 springs for 2 wheels! The two original ride springs could be > removed and things would still work with just the "third spring" for ride > and the anti-roll bar for roll. > > On race cars, a bump stop with "packers" (adjusting shims) is always fitted > on the third spring and this will control the _average_ minimum ride height > for the two wheels. Note that F1 cars have a plank down the center of the > car that must be kept off the road, and the original purpose of the "third > spring" becomes clear -- you can set packers (a bump stop) that controls > the height of the plank, regardless of the roll angle of the body. > > -- Doug > Douglas Milliken <[email hidden]> > Milliken Research Associates Inc.On Wed, 20 Jun 2001 11:04:36 +0100, "Ashley McConnell"
<[email hidden]> wrote:
>Ruud,
>
>I have managed to get combined slip to work (at least theoretically). I got
>a bit confused with Brian's stuff and ended up using G.Genta's
>"intermediate" solution.
Hi Ash, and others,
I just read about Brian's combined slip. Well what do you know, it
looks very familiar. In fact, it's exactly what Gregor uses (well, at
least this was the case a month or 2 ago).
In principle, you normalize the slip angle and slip ratio, based on
the max values (which are just 'D' in your average Pacejka formula,
plus the Sv or Sh, I forgot). This way, you get slip lateral and slip
longitudinal, which you can combine in a virtual slip vector.
This vector has X/Y values ranging from 0..1 and so makes up for a
nice virtualized friction circle. Then, if you get out of the circle
(sqrt(sa+sr)>1), you cut off the vector to lie exactly on the circle.
Then you take the amount of longitudinal and lateral forces by the
ratio of (the normalized) sa and sr; so Fx=...*sr, Fy=...*sa.
You can compare the virtualized friction circle (if you've done
graphics) by the normalized clip box that OpenGL for example uses;
every drawn vertex is scaled into a 1-1-1 box, so clipping becomes
much easier.
In fact, I've tried this method (thanks Gregor) in my wheel simulation
and indeed it did nice things. It's still there, so you can check
rwheel.cpp and check the few (3) #ifdef DO_GREGOR parts. ;-)
Perhaps I should pick it up again.
The strange thing though is that I have the impression that Genta's
first approach (which I posted before this one) seems to favor
longitudinal forces; the lateral forces diminish as you use up the
longitudinal force. In the above method however, you equally downsize
F_lat and F_lon so they're both equally present, so to say.
Now I wonder what direction is more right; is the longitudinal force
more prevalent than the lateral one? If not, Gregor's and Brian
Beckman's approach is quite a nice way to go...
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Free car sim : http://www.marketgraph.nl/gallery/racer/
Friction circle data is hard data to find (and expensive to measure).
See Race Car Vehicle Dynamics, p.57 for one set of data
that we were able to find that could publish.
-- Doug
Douglas Milliken <[email hidden]>
Milliken Research Associates Inc.
On Thu, 21 Jun 2001, Ruud van Gaal wrote:
Quoted text (49 lines)
> On Wed, 20 Jun 2001 11:04:36 +0100, "Ashley McConnell" > <[email hidden]> wrote: > > >Ruud, > > > >I have managed to get combined slip to work (at least theoretically). I got > >a bit confused with Brian's stuff and ended up using G.Genta's > >"intermediate" solution. > > Hi Ash, and others, > > I just read about Brian's combined slip. Well what do you know, it > looks very familiar. In fact, it's exactly what Gregor uses (well, at > least this was the case a month or 2 ago). > In principle, you normalize the slip angle and slip ratio, based on > the max values (which are just 'D' in your average Pacejka formula, > plus the Sv or Sh, I forgot). This way, you get slip lateral and slip > longitudinal, which you can combine in a virtual slip vector. > This vector has X/Y values ranging from 0..1 and so makes up for a > nice virtualized friction circle. Then, if you get out of the circle > (sqrt(sa+sr)>1), you cut off the vector to lie exactly on the circle. > Then you take the amount of longitudinal and lateral forces by the > ratio of (the normalized) sa and sr; so Fx=...*sr, Fy=...*sa. > You can compare the virtualized friction circle (if you've done > graphics) by the normalized clip box that OpenGL for example uses; > every drawn vertex is scaled into a 1-1-1 box, so clipping becomes > much easier. > > In fact, I've tried this method (thanks Gregor) in my wheel simulation > and indeed it did nice things. It's still there, so you can check > rwheel.cpp and check the few (3) #ifdef DO_GREGOR parts. ;-) > Perhaps I should pick it up again. > > The strange thing though is that I have the impression that Genta's > first approach (which I posted before this one) seems to favor > longitudinal forces; the lateral forces diminish as you use up the > longitudinal force. In the above method however, you equally downsize > F_lat and F_lon so they're both equally present, so to say. > > Now I wonder what direction is more right; is the longitudinal force > more prevalent than the lateral one? If not, Gregor's and Brian > Beckman's approach is quite a nice way to go... > > > 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 (11 lines)
>Ruud, > >I have managed to get combined slip to work (at least theoretically). I got >a bit confused with Brian's stuff and ended up using G.Genta's >"intermediate" solution. > >Have a look at my lovely graphs (under physics) - >http://sim.twistedtech.co.uk > >All the best >AshQuoted text (35 lines)
>Hi Ash, and others, > >I just read about Brian's combined slip. Well what do you know, it >looks very familiar. In fact, it's exactly what Gregor uses (well, at >least this was the case a month or 2 ago). >In principle, you normalize the slip angle and slip ratio, based on >the max values (which are just 'D' in your average Pacejka formula, >plus the Sv or Sh, I forgot). This way, you get slip lateral and slip >longitudinal, which you can combine in a virtual slip vector. >This vector has X/Y values ranging from 0..1 and so makes up for a >nice virtualized friction circle. Then, if you get out of the circle >(sqrt(sa+sr)>1), you cut off the vector to lie exactly on the circle. >Then you take the amount of longitudinal and lateral forces by the >ratio of (the normalized) sa and sr; so Fx=...*sr, Fy=...*sa. >You can compare the virtualized friction circle (if you've done >graphics) by the normalized clip box that OpenGL for example uses; >every drawn vertex is scaled into a 1-1-1 box, so clipping becomes >much easier. > >In fact, I've tried this method (thanks Gregor) in my wheel simulation >and indeed it did nice things. It's still there, so you can check >rwheel.cpp and check the few (3) #ifdef DO_GREGOR parts. ;-) >Perhaps I should pick it up again. > >The strange thing though is that I have the impression that Genta's >first approach (which I posted before this one) seems to favor >longitudinal forces; the lateral forces diminish as you use up the >longitudinal force. In the above method however, you equally downsize >F_lat and F_lon so they're both equally present, so to say. > >Now I wonder what direction is more right; is the longitudinal force >more prevalent than the lateral one? If not, Gregor's and Brian >Beckman's approach is quite a nice way to go... > >On Fri, 22 Jun 2001 07:32:50 GMT, Doug Milliken <[email hidden]> wrote:
>
>Friction circle data is hard data to find (and expensive to measure).
>
>See Race Car Vehicle Dynamics, p.57 for one set of data
>that we were able to find that could publish.
Thanks for the tip, I'll have a looksee tonight.
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Free car sim : http://www.marketgraph.nl/gallery/racer/
On 22 Jun 2001 23:54:40 GMT, [email hidden] (J. Todd Wasson) wrote:
...
It's probably a mix, as it is most of times. ;-)
There's a nice property of the 'vector trim' method; the amount of
'overflow' can signal an amount of slipping.
In SAE 980243, a tire model using a 3-dimension spring is shown.
Normally, you get F=k*d for 3 directions (for example,
F_vertical=wheel_rate*tire_vertical_deflection). The same is done for
longitudinal and lateral directions. To avoid overflowing deflections
(for example, a tire laterally bending 30cm is impossible), you apply
a friction circle. If the F=k*d calculated forces are outside limits
(the vector) you trim it (reducing long/lat equally by a factor) and
you recalculate what the maximum bending distances (the 'd'-s) can be.
The friction coefficient is decided on the sliding velocity (not slip
ratio). Sounds like a nice interdepence a bit (the less friction, the
less forces can be applied, the more slipping).
Anyway, the amount the vector is outside the friction circle is there
also an indicator for the amount of slipping in the tire (the
'overflow'). Same basic principle as Gregor/Brian use it seems.
> As far as the limited slip differential situation goes, I'm finding that my
>car tests with no wings rarely unlock the differential at all if the torque
>bias ratio goes much above 2. However, I'm not modelling drive torque reaction
>through the rear axle yet, which is a big factor in real cars, especially when
>turning right.
I only have a viscously locking differential yet. I'll have to reread
about the diffs in RCVD. I assume somewhat a torque bias ratio of 2
means that if the torque at one wheel is less than twice that of the
other wheel (connected to the diff), the differential starts opening
up? Hm, can't be right, since a higher ratio means more locking in
your diff.
So you fix the problem mostly by giving the front less grip? Shouldn't
this be more the work of the suspension (and possibly anti-rollbars
and differential)?
> The other car (around 450 horsepower) uses a 1.2 grip
>rear tire (closer to Nascar slicks), 1.13 grip at the front (94% of rear). A
>1.76:1 torque bias ratio allowed some inside rear wheel spin, going much higher
>than this kept the diff locked most of the time. They both end up with roughly
>the same handling balances on corner exit, so maybe those percentages will
>help.
I'll read more about the torque bias ratio, and try to set the fronts
a little more slippery than the rear, see what it does. The
differential locking seems to make a lot of difference, I can suddenly
spin the car round when going slow, while at higher speeds the car is
more stable. Almost like the diff is working the wrong way round. ;-)
Thanks for the help,
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 (14 lines)
> I think the longitudinal force is more prevalent. Perhaps I should think >about it more, but I doubt cutting the entire vector down to fit the circle >would work as correctly. Rather, I let the longitudinal force dictate how much >sideforce is available by leaving the longitudinal force alone, then trimming >the sideforce (changing the force vector's direction rather than just trimming >it to fit). However, thinking in terms of the movement of the contact patch >"slip", cutting the vector this way may end up doing the same thing anyway. >The way I'm currently doing it ends up killing off lateral force entirely if >the slip ratio's force exceeds the max allowable. > > However, this wouldn't really be right either, as it would imply that under >an extreme slip ratio situation at any slip angle, the tire would not even >distort laterally. This couldn't be the case. Perhaps Gregor's slip vector >usage is really the better way to go.Quoted text (10 lines)
> Concerning the skidding you're getting and the effects of the differential >model, I'll agree with Gregor that the setup has a lot to do with it. If I use >the same tires at all four corners (no load sensitivity, weight distribution >50/50 and 50/50), the car is very hard to keep from spinning. Any amount of >throttle will cause oversteer. > > I'm using one setup that has a fully open differential, with .85 grip >coefficient at the rears like a decent street performance tire. The front >tires on this car have 88% as much grip as the rears and it doesn't get >sideways too easily.
Interesting stuff on the tires, I'll have to read that paper again (I think
Chris sent that to me about the same time you got it.) My tire model is still
the old simple thing, so haven't got much into that, except for the brush model
excursion awhile back.
>I only have a viscously locking differential yet. I'll have to reread
>about the diffs in RCVD. I assume somewhat a torque bias ratio of 2
>means that if the torque at one wheel is less than twice that of the
>other wheel (connected to the diff), the differential starts opening
>up? Hm, can't be right, since a higher ratio means more locking in
>your diff.
No, it's the other way around. If the ratio of road reaction torques (I call
it TireTorque in my code) across one axle exceeds the torque bias ratio, the
diff will begin slipping (there's still a lot of resistance though, which is
calculated using the current torques and the maximum allowable torque bias
ratio, if I remember right). Otherwise, it remains locked. The key is to
calculate how much clutch torque is applied to both shafts/wheels as a function
of torque bias ratio. It changes dramatically all the time, so it's calculated
each step. I think I took the actual current calculated torque bias ratio
across the axle, then found how much the true clutch torque was exceeded, or
not exceeded (-/+.) This torque difference ends up accelerating the wheels on
that axle towards or away from each other. When they accelerate torwards each
other, I find friction reversal when the sign of the difference in velocities
changes. Then, if the actual torque is less than the clutch torque, I assign
it a locked state. From then on, it just checks to see if the torque bias
ratio is exceeded. If not, it just stays locked. If it does, then I assign an
unlocked state and they can accelerate away from each other. It took a ton of
messing with and I've got negative signs and IF statements all over the place
with, so it's a real inefficient hack, but it works right anyway.
Preload works the same way, but instead of being a ratio, it's the difference
in torques between the tires. In order for the diff to slip, the ratio AND the
difference have to exceed the torque bias ratio and preload simultaneously.
Yes, you're right, but my goofy tire model doesn't account for load
sensitivity, so stiffening up something won't change the under/oversteer
characteristics anyway. That leaves me with differential settings, downforce,
and tire grip as the main handling adjustments. I'm working on a new
suspension model now (nearly full kinematics, double wishbone independent
system) that looks like it predicts both trackwidth and camber change with
wheel travel really well, and allows the spring installation points to alter
wheelrate on the fly, progressively. This isn't in the model yet, but is a
seperate program for now. I think induced camber from steering with kingpin
and caster angle will work well too. This should really improve things if I
get around to attempting to catch up to you guys in the tire modelling area
soon, otherwise, there's really no point except for cool looking wheel motions
in the graphics, and better spring and damper force reactions :-) I'm saving
that for last, since tire modelling is a never ending ordeal anyway. I'm
hoping to hook up anti-roll bars in a kinematically correct fashion to the arms
too, but we'll see :-)
>I'll read more about the torque bias ratio, and try to set the fronts
>a little more slippery than the rear, see what it does. The
>differential locking seems to make a lot of difference, I can suddenly
>spin the car round when going slow, while at higher speeds the car is
>more stable. Almost like the diff is working the wrong way round. ;-)
>
You've got it right if you're talking about applying lots of power at low
speed. At high speed, the locked differential keeps the car noticeably more
stable and especially helps stability under braking, although it tends to push
through corners. However, the "ultimate" racing diff supposedly should be
fully open under braking, and locked under power, rather than the other way
around.
Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
Quoted text (8 lines)
>> I'm using one setup that has a fully open differential, with .85 grip >>coefficient at the rears like a decent street performance tire. The front >>tires on this car have 88% as much grip as the rears and it doesn't get >>sideways too easily. > >So you fix the problem mostly by giving the front less grip? Shouldn't >this be more the work of the suspension (and possibly anti-rollbars >and differential)?>I'll have to visualize the splines; I drove an oval with splines
>yesterday and it's better, but in the corners it has some modulation
>at the wheel, some jittering, which may be due to the difference in
>the 2 triangles. Still, a lot better than WITHOUT splines. :)
>And somehow the shadow intersections go bad; perhaps the two problems
>are interrelated.
Your post on the splines really got me thinking the other day! It seems to
me that there will be jittering if the two triangle's don't have parallel
sides. The splines won't match up at the border. On a banked curve, the top
and bottom (by the wall and infield) might be parallel, but the other two sides
won't be. This will mess it up, I think.
I'd thought of doing this type of thing awhile ago. Didn't know this is all
that "splines" really were :-)
BTW, you're environment mapped cars look fantastic! How tough is it to load
in an SCGT car into an OpenGL system? My cars are pretty interesting
looking..... The Indycar isn't too bad, but my other one is a gorgeous rainbow
looking car! lol
Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
On 25 Jun 2001 22:51:19 GMT, [email hidden] (J. Todd Wasson) wrote:
> Your post on the splines really got me thinking the other day! It seems to
>me that there will be jittering if the two triangle's don't have parallel
>sides. The splines won't match up at the border. On a banked curve, the top
>and bottom (by the wall and infield) might be parallel, but the other two sides
>won't be. This will mess it up, I think.
Hm, I'm having trouble visualizing what would go wrong then. I have a
nice idea though; if I draw filled gouraud-shaded polygons with the
color being the height from the spline, I might get a visual on the
spline surface.
There are 2 splines; 1 runs on the left side of the road, 1 on the
right. So basically, these should be relatively smooth, right?
(although I'm not sure anymore if Hermite is C2 compliant, like
B-splines)
Then, for a middle of the road position, I linearly interpolate
inbetween what I get at the left spline, and what I get at the right
spline. Perhaps you're right if the UV coordinates in the 2 triangles
don't vary in the same 'spacing' way. I mean, the V coordinate for one
triangle might be more 'dense' than the other, therefore creating just
a bit of a different spline.
Perhaps I should really do a quad intersection, and since that mostly
is done by 2 triangle hits (as I do now)... :) I could just do a
distance to vertex (4 vertices in this case) and average out the
distances to come up with a different kind of UV coordinate, which
should be less sensitive to the shape of the triangles (which is
indeed important, but most triangles look relatively the same shape at
Carrera at least). I'm off to the beach now, so I'll think about it
some more in the sun. :))
> I'd thought of doing this type of thing awhile ago. Didn't know this is all
>that "splines" really were :-)
Most good things are simple, esp. for realtime applications. :)
It's just you can think of so many more complex things, like real
Bezier patches, although a ray-Bezier intersection function might be
harder (although it is still a parameteric function collection, hm).
> BTW, you're environment mapped cars look fantastic! How tough is it to load
>in an SCGT car into an OpenGL system? My cars are pretty interesting
>looking..... The Indycar isn't too bad, but my other one is a gorgeous rainbow
>looking car! lol
Thanks. :) I must say, lighting does it all in the end. The envmapping
just makes it shiny, but also seems to give a bit of specular
highlighting effects. And on the PC I use separate specular lighting
(extension), which gives some highlights on top of the textures.
I use the VRL format in a way, transformed to VRML; VRML is an easy
format, BUT very inefficient if you want to load it in in a flexible
way. My loader really generates a lot of triangles and such when it
loads it, that's my the Modeler has the important Optimize button.
After that, it's just a vertex array with indices. The VRML format
doesn't really map that well to vertex array without optimization. You
could try to create a converter from DOF (my file format, explained
with hex dumps on my website) to your own format. It's not that tough,
except perhaps for the materials. That would make it easier probably
to get SCGT cars across.
Cheers,
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Free car sim : http://www.marketgraph.nl/gallery/racer/
>Hm, I'm having trouble visualizing what would go wrong then. I have a
>nice idea though; if I draw filled gouraud-shaded polygons with the
>color being the height from the spline, I might get a visual on the
>spline surface.
That's clever :-)
As far as the rest of the spline stuff goes, I don't know what Hermite and C2
compliance is or any of that stuff. I've seen the terms online but never
studied any of it. This might be totally different and amateurish in
comparison to what you're trying to do, but what I was imagining was something
like this:
Top and bottom of track are two "splines" (if that's what I'm really thinking
of here, I haven't done any of this before.) I was thinking of doing just a
curved bank that doesn't change angle or twist or anything. One 10 meter
section (or whatever length) is defined as two triangles, with the V
coordinate parallel to the top and bottom edge. My "spline" would be nothing
more than a sine wave function that adds a little depth throughout the
triangles. If they were parallel, everything would be peachy and perfect for
doing an incline change at the bottom or top of a hill. The depression
wouldn't be dependent on the left-right track position then.
The problem I saw was, for the road to curve while banking, the bottom edge
has to be shorter than the top. Then, the depression must change according to
both V and U. Maybe your linear interpolation would do this just fine, as I
wasn't thinking of using two seperate splines (just a sine function that varied
with a normalized V or U coordinate.) All in all, for my simpler sine function
of just trying to get a truly curved track surface would be to take the U coord
(left right position on track), find the distance to one edge along the V
direction (treat the whole thing as a quad), normalize it, then do depression =
Sin(V) * .002 or whatever. Seems like it ought to work just fine for banked
curves and road grade changes at least.
I'd still like to hear your thoughts on this after the beach, so fire away
:-)
I'd really like to see an SCGT car in my proggie! I don't know anything
about 3-D file formats yet though. Are the SCGT files a list of quad coords,
then a list of triangle strips, then a list of whatever? I'll take a look at
your site and try to find the hex dumps you talked about.
Thanks,
Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
Quoted text (14 lines)
>Thanks. :) I must say, lighting does it all in the end. The envmapping >just makes it shiny, but also seems to give a bit of specular >highlighting effects. And on the PC I use separate specular lighting >(extension), which gives some highlights on top of the textures. >I use the VRL format in a way, transformed to VRML; VRML is an easy >format, BUT very inefficient if you want to load it in in a flexible >way. My loader really generates a lot of triangles and such when it >loads it, that's my the Modeler has the important Optimize button. >After that, it's just a vertex array with indices. The VRML format >doesn't really map that well to vertex array without optimization. You >could try to create a converter from DOF (my file format, explained >with hex dumps on my website) to your own format. It's not that tough, >except perhaps for the materials. That would make it easier probably >to get SCGT cars across.
Just looked at the DOF info at your site. Would you mind if I used a few of
your textures? How can I look at the DOF files? Do I need 3D studio? Or is
there a freeware thing I can use? Or can I open it as a random access file and
pull out data one record at a time?
I'd really like to just get one of the cars up and running, without any
textures or lighting. (I just played around with OpenGL lighting last night,
very funny looking when you have no idea what you're doing!!)
Thanks for any help,
Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
One more thing. I see that I can use your modelor to load DOF files doh!!
When toggling to burst viewing, this shows bursts of similar primitives? If
so, can I make a loader by reading DOF files as random access, one record at a
time?
Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
On 26 Jun 2001 22:50:15 GMT, [email hidden] (J. Todd Wasson) wrote:
>
> Just looked at the DOF info at your site. Would you mind if I used a few of
>your textures? How can I look at the DOF files? Do I need 3D studio? Or is
>there a freeware thing I can use? Or can I open it as a random access file and
>pull out data one record at a time?
DOF is only supported by Racer and it's Modeler (as you found out ;-).
Although I'm against 'Yet Another 3D Format' I needed it for fast
loading and close integration to my rendering capabilities (VRML is
too flexible for example, costs time to optimize and produces files
that are far too large).
Feel free to use the models. Though if you use them, note that the
cars are actually copyrighted by their creators, which are in a README
file somewhere (data/cars/ferp4/README.txt for example).
If I recall some BASIC work I did in a previous life, the random
access file only gives access to records of a fixed size? If so, it's
not that handy, you'll have to be able to read it byte by byte.
Perhaps the dgeode.cpp/dgeob.cpp will help (probably somewhere in the
source tree). If you can't find it, I can mail it to you, or you could
wait, since I'm planning to put up v0.4.6 tonight, if I get the ports
done without too much problems tonight. That should include the entire
D3 source code.
> I'd really like to just get one of the cars up and running, without any
>textures or lighting. (I just played around with OpenGL lighting last night,
>very funny looking when you have no idea what you're doing!!)
Most lighting problems appear because you either have no normals (so a
flat triangle may visually seem to point one way, but the normal can
be anything), or the placement of your glLightfv(POSITION) command,
which is a bit whacky, but understandable (after rereading the gllight
man page). Try setting it before and after your camera translations.
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Free car sim : http://www.marketgraph.nl/gallery/racer/
On 26 Jun 2001 23:02:49 GMT, [email hidden] (J. Todd Wasson) wrote:
> One more thing. I see that I can use your modelor to load DOF files doh!!
>When toggling to burst viewing, this shows bursts of similar primitives?
Sort of. A geode (name stolen from SGI's Performer; geode=geometrical
node) contains 1 or more geobs (geometrical objects). The geob's share
the same shader actually, although the concept is not really worked
out yet in D3 (can't think of a good general and fast design yet).
You see the different geobs. The primitives are all triangles. The
geobs used to be able to have bursts, which maps a bit onto .ASE files
(from 3D Studio Max). The materials of Max can be trees, and you'd
have a material and a submaterial. I did that with bursts, but now it
only works with 1 burst, IIRC.
So in short, what you see is 1 geob, which uses 1 material/texture.
These can be drawn using 1 glDrawArray() call (see dgeob.cpp). The
property that a geob has only 1 texture is used in rendering the
track, where the geobs are not painted at first but stored in a big
list, after which all geobs with the same texture are drawn together
(sequentially) to avoid texture switching, which seems to be a
bottleneck in most apps.
> If
>so, can I make a loader by reading DOF files as random access, one record at a
>time?
I don't know how flexible records work anymore; can you just read 4
bytes and check their value as a string for example? Like 'read
fn,c(4); if c="DOF1" then read_chunk1'?
It's highly basic on Amiga's IFF format btw (which allows chunks to
appear that you may not know of or do not handle), which is also the
same as used in WAV files (RIFF) and AIFC etc. (it that helps ;-))
The byte-order is PC-oriented btw, you shouldn't have to byteswap
4-byte integers (32-bit).
Hope this doesn't put you off yet. ;-)
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Free car sim : http://www.marketgraph.nl/gallery/racer/
On 26 Jun 2001 22:22:32 GMT, [email hidden] (J. Todd Wasson) wrote:
>>Hm, I'm having trouble visualizing what would go wrong then. I have a
>>nice idea though; if I draw filled gouraud-shaded polygons with the
>>color being the height from the spline, I might get a visual on the
>>spline surface.
>
> That's clever :-)
Thanks. It may need some subdivisions though, so I have a new easier
idea, which is to put a graph in the view which displays the value of
a variable (just like the speedometer is a view element which displays
the value of 'kmh' in a certain way, namely a rotating polygon (the
needle)). I could then see live how the track height is varying at a
wheel, for example. If I have 250 points in the graph, it shows 1
second at 250Hz integration, and may still be fast enough for realtime
displaying.
> As far as the rest of the spline stuff goes, I don't know what Hermite and C2
>compliance is or any of that stuff. I've seen the terms online but never
>studied any of it.
It's not really hard; splines are parametric curves that you can use
to go smoothly from 1 point to another. 2 types exist; 1 that goes
through the control points (like Hermite and Catmull-Rom), some don't
(B-splines).
What you do is mix a couple of cubic formulae from point to point, and
that magically follows a smooth line from point1 to point2. The choice
of the formulae is a big one (lots are possible) and have varying
properties. Like in CorelDraw for example, you can also play around
with the tangents to accentuate the curve here & there.
C2 continuity is that the derivative of the derivative doesn't jump
around (hope I say this correctly). C0 and C1 also exist; let's take
two lines; \/
These touch eachother, so are C0 continous. C1 continuous means the
derivate must also connect everywhere. So the \/ is NOT C1 continuous
since the derivative jumps from -1 to +1. A smooth line has C1
continuity. You can go further and define C2 continuity, in that the
derivative of the derivative is smooth as well.
Let's just say, with C2 you have a really smooth line. :)
Yes, but how do you find your U coordinate? Projection along the
normal of the left and right track edges?
And the distance to one edge along the V direction, which edge would
you take? The quads are not nicely perpendicular in an oval curve.
I've thought about it a bit on the beach; the quad seems the way to
go, but I have to figure out a method with which I can get the U and V
coordinates which move nicely over the quad.
The triangle system is flawed for sharp curves; exactly the same thing
as trying to texture a deformed quad in OpenGL (or whatever, try 3d
Studio Max; same thing can be done there). The one triangle is far
smaller than the other, so the density suddenly changes from one
triangle to the other.
I need to have a function where I have a quad, that's not necessarily
well formed, which gives me U/V coordinates. Perhaps based on the
distances to the vertices, or distances to the edges, or distances on
the edge normals (this seems a nice one). Will have to draw a little,
the sand was too coarse to figure things out. ;-)
I'll ask in the algorithms newsgroup after I retry Google.
> I'd really like to see an SCGT car in my proggie! I don't know anything
>about 3-D file formats yet though. Are the SCGT files a list of quad coords,
>then a list of triangle strips, then a list of whatever?
Actually SCGT cars use their own format, VRL (look at the tutorial on
my site on converting SCGT cars). Didn't see any loaders for it for
regular 3D apps. You can use Tony Hirsts' VRL2VRML though to get .wrl,
which is readable (ASCII). It can do nasty polygons though, and in DOF
I convert all the troublesome polygons (>3 vertices) to triangles.
So VRL files can contain a 10-vertex polygon. Nice when you have a
software rendered, quite useless for 3D cards (people might disagree
here though). No triangle strips so, but single polygons. In DOF,
there's only the triangle; it's all GL_TRIANGLES. Although in the
future I *might* try a strip one day, as it seems faster (nVidia has a
stripgenerator, and there's an SGI one as well, which is what I've
read slower).
WRL files (VRML) use non-triangle polygons too. For ease of debugging
though, it might be your format. For ease of painting and
organization, DOFs are probably a little easier. And ofcourse, I'm
biased towards DOFs. ;-) Would be great if someone made an exporter
from DOF to WRL again, for example, and so I should push DOF a little.
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 (10 lines)
> The problem I saw was, for the road to curve while banking, the bottom edge >has to be shorter than the top. Then, the depression must change according to >both V and U. Maybe your linear interpolation would do this just fine, as I >wasn't thinking of using two seperate splines (just a sine function that varied >with a normalized V or U coordinate.) All in all, for my simpler sine function >of just trying to get a truly curved track surface would be to take the U coord >(left right position on track), find the distance to one edge along the V >direction (treat the whole thing as a quad), normalize it, then do depression = >Sin(V) * .002 or whatever. Seems like it ought to work just fine for banked >curves and road grade changes at least.Quoted text (8 lines)
>> If >>so, can I make a loader by reading DOF files as random access, one record at >a >>time? > >I don't know how flexible records work anymore; can you just read 4 >bytes and check their value as a string for example? Like 'read >fn,c(4); if c="DOF1" then read_chunk1'?Quoted text (15 lines)
>>>Hm, I'm having trouble visualizing what would go wrong then. I have a >>>nice idea though; if I draw filled gouraud-shaded polygons with the >>>color being the height from the spline, I might get a visual on the >>>spline surface. >> >> That's clever :-) > >Thanks. It may need some subdivisions though, so I have a new easier >idea, which is to put a graph in the view which displays the value of >a variable (just like the speedometer is a view element which displays >the value of 'kmh' in a certain way, namely a rotating polygon (the >needle)). I could then see live how the track height is varying at a >wheel, for example. If I have 250 points in the graph, it shows 1 >second at 250Hz integration, and may still be fast enough for realtime >displaying.Quoted text (24 lines)
>> As far as the rest of the spline stuff goes, I don't know what Hermite and >C2 >>compliance is or any of that stuff. I've seen the terms online but never >>studied any of it. > >It's not really hard; splines are parametric curves that you can use >to go smoothly from 1 point to another. 2 types exist; 1 that goes >through the control points (like Hermite and Catmull-Rom), some don't >(B-splines). >What you do is mix a couple of cubic formulae from point to point, and >that magically follows a smooth line from point1 to point2. The choice >of the formulae is a big one (lots are possible) and have varying >properties. Like in CorelDraw for example, you can also play around >with the tangents to accentuate the curve here & there. >C2 continuity is that the derivative of the derivative doesn't jump >around (hope I say this correctly). C0 and C1 also exist; let's take >two lines; \/ >These touch eachother, so are C0 continous. C1 continuous means the >derivate must also connect everywhere. So the \/ is NOT C1 continuous >since the derivative jumps from -1 to +1. A smooth line has C1 >continuity. You can go further and define C2 continuity, in that the >derivative of the derivative is smooth as well. > >Let's just say, with C2 you have a really smooth line. :)Quoted text (21 lines)
>> The problem I saw was, for the road to curve while banking, the bottom >edge >>has to be shorter than the top. Then, the depression must change according >to >>both V and U. Maybe your linear interpolation would do this just fine, as I >>wasn't thinking of using two seperate splines (just a sine function that >varied >>with a normalized V or U coordinate.) All in all, for my simpler sine >function >>of just trying to get a truly curved track surface would be to take the U >coord >>(left right position on track), find the distance to one edge along the V >>direction (treat the whole thing as a quad), normalize it, then do >depression = >>Sin(V) * .002 or whatever. Seems like it ought to work just fine for banked >>curves and road grade changes at least. > >Yes, but how do you find your U coordinate? Projection along the >normal of the left and right track edges? >And the distance to one edge along the V direction, which edge would >you take?>Feel free to use the models. Though if you use them, note that the
>cars are actually copyrighted by their creators, which are in a README
>file somewhere (data/cars/ferp4/README.txt for example).
>
Ok, will do. I won't distribute anything without giving proper
credit/payment, we know how much work this is :-)
>If I recall some BASIC work I did in a previous life, the random
>access file only gives access to records of a fixed size? If so, it's
>not that handy, you'll have to be able to read it byte by byte.
I can read the files in binary, byte for byte, so it should work out. It'll
take me awhile to do it right, though! I've looked through the dgeob.cpp and
dgeode.cpp files. Too bad most of it looks greek to me. Will have to study
them more later.
Yes, I'm getting some wierd effects all right, although I'm sure it's because
I'm not transforming properly before calling glLightfv. Will play around more
and pop into the OpenGL group for help. Hope you'll be there ;-)
Thanks for all the help,
Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
Quoted text (11 lines)
>> I'd really like to just get one of the cars up and running, without any >>textures or lighting. (I just played around with OpenGL lighting last >night, >>very funny looking when you have no idea what you're doing!!) > >Most lighting problems appear because you either have no normals (so a >flat triangle may visually seem to point one way, but the normal can >be anything), or the placement of your glLightfv(POSITION) command, >which is a bit whacky, but understandable (after rereading the gllight >man page). Try setting it before and after your camera translations. >On 30 Jun 2001 17:10:50 GMT, [email hidden] (J. Todd Wasson) wrote:
...
>record number 1 written to a long integer returns "826691396." I'm not sure
>record number 2 would automatically be the next four bytes in this case though,
I'd say so. It's probably the old semi-database format which some old
apps used to use. :)
You should always open it in binary mode. Probably every file in your
entire life even, but that's just my own principle. On the website is
perhaps a more verbal explanation of the DOF1 format. Only 1 DOF1
identifier should be at the top of the DOF1 file, indicating... a DOF
version 1 file.
The chunks are mostly char id[4]; int32 size; where 'size' is the
length of the upcoming chunk (though this is useful mostly to skip the
chunk if you can't handle it).
There are non-4 byte chunks, I'm sure; most of time it WILL be 4-byte
aligned but there are strings that are stored on 1-byte boundaries (I
know, it's not really cute).
>>Hope this doesn't put you off yet. ;-)
>
> Haven't given up just yet!
>
> Any suggestions or thoughts?
Make it a parser; it's a top-down document, DOF1 being the tree root,
so to say, and when you find a material for example, you enter a
function which reads the material. You have materials and geobs that
you will encounter. These use different IDs to load/save different
things. It's all done in a way so extending it is easy (and in fact
has been done in v0.4.6, where a new flags chunk was added to the
materials).
Good luck,
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 (7 lines)
> Oops, just now, I tried pulling and storing as a four byte ASCIIZ type. >Record number one shows "DOF1" as you indicated :-) I'll blast through and see >how many of these I find right now. (I'm working and writing at the same time >here.) Ok, it looks as though that's the only "DOF1" showing up. Is that >right, or should there be more? I might not have checked the entire file. Are >your DOF files made entirely of 4 byte chunks? If not, I can open it in binary >mode(I'm confused enough as it is, would rather stick to another method ;-))On 30 Jun 2001 17:25:00 GMT, [email hidden] (J. Todd Wasson) wrote:
Lol. In fact, I did a raytracing separate app yesterday to look at the
UV coordinates still, and you definitely see a sharp line running
through the separating edge, the U coordinate does very well, but the
V coordinate is really misformed. I tried another dot-product approach
assuming parallel lines, but that's quite useless at this point
(although it has less of the line's visual deformation).
I'll have to reread Eberly's approach to projective texture mapping
(which should get it right, but is quite complex).
>>Let's just say, with C2 you have a really smooth line. :)
>
> Makes absolutely no sense to me at all :-) If I saw some graphs of this,
>it'd probably make sense though. I'll just take your word for it for now :-)
Pick up a book on graphics, hehe, most of them explain this, with
pictures (probably available on the net too) and explain G0/G1/G2
continuity as well.
>I'll need DX8 to run Racer now and haven't downloaded it because I'm afraid it
>might crash my laptop with the problems many have reported. Too bad, with DX7a
>I can drive the car, but there're no graphics (only sound and mouse control.)
If I'm correct you don't need DX8 to run Racer v0.4.6, just DX7. On
ATI boards in Win98, the environment mapping seems to crash the
drivers and the board even. A matter of buggy drivers that is goes so
far, but turning envmapping off (gfx.ini => envmap.enable=0) seems to
work for most and gets you back the FPS again.
Ah! Well, there's the tricky bit. :)
> I made a very cheesy
>track editor that lets you create the files using radius of curvature, degree
>step resolution of the curve, angle of incline (no banking in it yet), or
>straight length. This lets me come up with flat tracks made of triangles
>really quickly.
Yes, I did that; flat tracks, but I've left it behind now since it had
some problems and the tracks were nothing like modeled (VRML) ones.
Though it would be great still as a basis to create your track model
from. But then again, you can't beat 3D model packages these days.
> Something along the lines of an edge normal solution is what I was thinking
>too. Guess it's time for a visit to the algo newsgroup.
I tried that yesterday. Didn't really work well once the lines are not
totally parallel. And that does happen a lot here, although you could
force your way through in your generated tracks ofcourse.
There's a link, ref [153] in the book 'Real Time Rendering' which
seems to do barycentric coordinates for polygons. Somewhere in
acm.org... Haven't got the book with me though.
> About the DOF files, if they're all just a list of triangles, that's very
>nice for a rookie like me :-)
Even though strips may be faster, it's quite good as it is, and it's a
hassle creating strips (going through a couple of packages, supporting
it nicely). And I don't support them yet. Have no idea what the
increase would be. As new machines run Racer at 200fps (Carrera) I
don't think it should have big priority at this point too. ;-)
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 (10 lines)
>>Thanks. It may need some subdivisions though, so I have a new easier >>idea, which is to put a graph in the view which displays the value of >>a variable (just like the speedometer is a view element which displays >>the value of 'kmh' in a certain way, namely a rotating polygon (the >>needle)). I could then see live how the track height is varying at a >>wheel, for example. If I have 250 points in the graph, it shows 1 >>second at 250Hz integration, and may still be fast enough for realtime >>displaying. > > Even more clever :-)Quoted text (7 lines)
>>Yes, but how do you find your U coordinate? Projection along the >>normal of the left and right track edges? >>And the distance to one edge along the V direction, which edge would >>you take? > > > I don't know how to find the V or U coordinate yet :-)On 30 Jun 2001 17:30:06 GMT, [email hidden] (J. Todd Wasson) wrote:
Pick up a book on C (or C++); it will definitely help, since C is
really just the same as BASIC, a 3rd generation language. Just with
some obscure writing, in the grand ole Unix style. ;-)
See you in the OpenGL lounge then. ;-)
Just move the glLightfv() command around your projection/modelview
transformations and you'll see the differences. Better to read the red
book and see how it was designed though. :)
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Free car sim : http://www.marketgraph.nl/gallery/racer/
