[ODE] Rigid Body moving to fast,
passing through tri-mesh when should collide
shalinor at gmail.com
Mon Aug 29 09:16:57 MST 2005
Well, this is just "one of those problems" you see with high velocity
entities vs paper-thin triangles in a discretely stepped phys
environment. The easiest solution may well be to adopt the heightmap
geom which is, I think, still in contribs - that would give you a
"solid" terrain that would properly de-penetrate objects, rather than
a paper thin terrain that's easy to warp.
My (more general, not just terrain) solution, while not physically
accurate, is to attach a ray geom to the back of any fast moving
object, and set that ray geom's length based on the speed of the
projectile (that is, make the ray's length equivalent to the distance
the ball can "jump" in a single time step). This way, all I have to
do is look for a contact point anywhere on the island each timestep.
If I find one, it's a hit, and I adjust the center-point of that phys
entity to match the determined contact point.
This works fine for me, only caring about bullets and arrows (both of
which either richochet or just stop at the determined contact point),
but I'm not sure how you would go about convincing the system to
properly generate the contact at that point that would give your ball
the proper bounce.
On 8/29/05, Matt Durfee <mattdurfee at hotmail.com> wrote:
> We have made a golf game, and sometimes the ball will pass through the
> trimesh completely without detecting collision. This generally happens when
> the ball is up against a wall, and we shoot at the wall with full power. It
> sometimes happens when we chip the ball from a higher plane to a lower
> plane. In both instances the speed at which the ball is moving is very
> fast. If we lower the amount of force applied when hitting the ball the
> problem is solved, but we would like to know if there is a way we can adjust
> the timestep or set the CFM or ERP to help with this problem. FYI, Our
> current timestep is 0.005 (called n amount of times based on the elapsed
> time) and we are using ODE 0.039. We would appreciate any suggestions.
> Matt Durfee
> mattdurfee at hotmail.com
> ODE mailing list
> ODE at q12.org
Lead Developer, Elium Project
More information about the ODE