rec.autos.simulators

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.racesimcentral.net/
Free car sim  : http://www.racesimcentral.net/

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

        Milliken Research Associates Inc.

  You, Ruud, Gregor, Sebastien, and anybody else doing this kind of thing might
want to download the demo of the SAS program at my site and take a look through
the transmission window.  I've got almost 80 transmissions listed in the menus
there with proper gear ratios, although they're almost all American.  

  FWIW,

Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com

  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 t***
the sideforce (changing the force vector's direction rather than just t***
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.

 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.

 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.  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.  

Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://www.racesimcentral.net/

Ruud van Gaal, GPL Rank +53.25
Pencil art    : http://www.marketgraph.nl/gallery/
Free car sim  : http://www.marketgraph.nl/gallery/racer/

...

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.

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)?

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.racesimcentral.net/
Free car sim  : http://www.racesimcentral.net/

  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

  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.

  >>  I'm using one setup that has a fully open differential, with .85 grip

  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 :-)

  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

  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

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. :))

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).

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/

  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

  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

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.

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/

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.

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/