[ODE] Re: Collision triangle culling

[Jani Kajala]

> But thanks for the suggestion. I'll go for the continuous collision checks;
> they're not really that expensive given the right data structures. Not even

You right, the checks are not that expensive (especially as memory speed tends
to be the bottleneck in many situations with current n GHz CPUs). Besides,
racing games are kind of prime candidates for continuous collision checks:
Objects move very fast and geometry collided against is relatively simple.

You might try to check collisions with spheres (spheres in positions of tires)
instead of OBB as car hull. Continuous sphere checks are simpler than continuous
OBB checks, and in most cases you won't notice the difference. You can use
sphere checks even to check collisions against other cars: You could use tire
positioned spheres from the first car and OBB hull from the second car.

You could even go polygon level detail with the other car and feed back effect
of tire sphere collisions to the springs.. So you could even drive *over* other
cars. =) To avoid troublesome geometry tho you probably would need to compute
convex hull of the other car and then check collisions against that, but
anyway...


Regards,
Jani Kajala
http://www.helsinki.fi/~kajala

----- Original Message -----
From: "Ruud van Gaal" <ruud@marketgraph.nl>
To: <ode@q12.org>
Sent: Thursday, December 06, 2001 1:16 PM
Subject: [ODE] Re: Collision triangle culling


> ...
> > From: "Jani Kajala" <jani@sumea.com>
> ...
> > This is not really an aswer to your question but anyway...
> > Usually racing games
> > don't go that far in simulating collisions. Usually the
> > tracks are designed so
> > that 'invisible fence' starts at some distance, and other
> > objects which get
> > collided against have some reasonable volume.
>
> I'm trying to stay out of that, so you can drive a terrain if you want to
> (like in Monster Truck Madness, well, the few times I've played it). Setting
> such a radius of every object would be too limiting I think.
> But thanks for the suggestion. I'll go for the continuous collision checks;
> they're not really that expensive given the right data structures. Not even
> 1% running at 1000Hz it seems on my PII-400/GF3 (but ofcourse, the more
> graphics, the less the physics take).
>
> > From: "Erwin de Vries" <erwin@vo.com>
> ...
> > What we did was quite easy. Check if the center of the box is at the
> > positive side of the plane. Beware though. This does not give perfect
> > results in all cases. This was also a problem i didnt quite
> > know how to solve.
>
> Thanks for that suggestion, should indeed work in 99% of the cases I guess.
> Ofcourse, the quantum effect of a speeding car jumping through a fence in
> one timestep isn't catched, but well.
> Given that aerodynamics will make sure a car doesn't move in any direction
> faster than say, 400 km/h... This is 111 m/s. I step at about 250Hz, which
> then amounts to 0.44 m per step. Quite a lot actually, but should work most
> of the time. Little things like broken off wheels and such will probably
> need a smaller timestep or double checking (if speed>highspeedThreshold then
> check at both p and p+v/2; for example, hm).
>
> In fact, previously I had a better but slower function. I used Dave Eberly's
> OBB-triangle intersection function (I still do, but more as a
> TestIntersection than a FindIntersection), which takes the OBB's linear
> velocity and calculates the time at which the OBB touches the triangle (so
> quantum effects can be overcome). However, this requires more triangles to
> check, and was quite a bit slower.
>
> Ruud
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
>