rec.autos.simulators

Todd Wasson
Racing Software
http://www.racesimcentral.net/
http://www.racesimcentral.net/

...

I recently read a very interesting article on floating point
precision. The boundary was something (when using floats) of 10^-4
(0.0001) for the stepsize. After that, floating point roundoff got
worse, so your accuracy actually suffers while you'd think a 0.00001
(10^-5) would give you more.
So with 6000Hz you're already pretty close to the limit, unless you
move to doubles, which for game purposes at least totally overboard.

I'm not sure what you mean, but ODE (www.opende.org IIRC) does
multiple contacts quite nicely. Still, I manage to average out all the
generated contact points into 1 (just average the normals and contact
depth) and it still continues to do nicely (if you hit a pilar at the
edge; don't do this at home, kids).

I agree that a software library which handles low-end things (like
generating contacts between various types of primitives) looks far
more useful. But let's not stop them from trying to think of
something; they might have a brilliant insight somehow which we're
overlooking. ;-)
After all, that's how revolutions come to pass; everybody thinks
something is impossible, then someone approaches the problem in
another way.

Unless the hardware is significantly faster at the brute force method.
That's what Z-buffers are doing for example; wasting a lot of power
where you could mostly just sort your polygons. But in practice, the
hardware is faster than your Z-sorter often.

Feels very cool too. :)

Ruud van Gaal
Free car sim: http://www.racer.nl/
Pencil art  : http://www.marketgraph.nl/gallery/

Just to add some number for the lurkers to put things in perspective:  If it
took 10 math ops to model wear on a particular part and you wanted to dedicate
1% of a low end PII - 333MHz processors time to modelling part wear, you'd be
doing wear for 50,000 parts and might not even notice a frame rate hit.  Jack
that up to a more complex model with 50 calculations per cycle and just do wear
every 10 cycles (1/10th as often) and you're doing 100,000 parts in real
time...  Try it on a P4-2.66GHz (8 times faster math ops) and you could be
doing something like a million parts.  How many parts do you want and how many
cars are there?  Part wear is close to free.

Maybe a full blown engineering approach could be done after all for a few
hundred parts...

Todd Wasson
Racing Software
http://PerformanceSimulations.com
http://performancesimulations.com/scnshot4.htm

I was referring to impulse methods, not penalty.  I haven't yet found a paper
or discussion where multiple impulse calculations were made for the rigid body
case.

Yeah, you're probably right.  

You finally got to drive it? :-)

Todd Wasson
Racing Software
http://PerformanceSimulations.com
http://performancesimulations.com/scnshot4.htm

...

Ah indeed, sorry about that. ODE's penalties seem ok though; it allows
for some interpenetration, which probably can save you from doing too
much collision checks to make sure every object doesn't
interpenetrate.
And there was a linear step collision solver that was talked about
some time ago (I stopped reading the maillist) which avoided big
matrices and instead could do it with little matrices step by step
(and faster too).

Yep, some time ago. :) Actually one drove it once.
Now that my cars can tumble over without flying into space though, I
might need to test again. ;-)

Ruud van Gaal
Free car sim: http://www.racer.nl/
Pencil art  : http://www.marketgraph.nl/gallery/

Hehe, right.  I'm sure it was a too dangerous before that problem was fixed :-P
 YEAAAAH!!!!!!  (hole in ceiling... legs dangling...)

Todd Wasson
Racing Software
http://PerformanceSimulations.com
http://performancesimulations.com/scnshot4.htm