Menu ▾ ▴

#161 Fix for problem with Gimpact vs Heightfield

None
closed
nobody
None
5
2014-02-04
2010-03-04
Tilmann Zaeschke
No

The problem occurs for example in demo_heightfield. Dropping a trimesh, it will bounce off the heightfield and then sink into the ground.
This fix solves the sinking into the ground, not the bouncing (and penetrating) of the trimesh.
The problem was that GIMPACT stores the AABB internally, but the heightfield collider only adjust the AABB stored in dxGeom. Therefore the collision of a plane (in the heightfield collider) with the GIMPACT trimesh yielded strange results.
The fix is that the heightfield collider now uses a temporary oriented BB to check for collision with any objects. If any BBs collide, the collider now rotates the plane instead of the colliding object.

See also discussion here: http://groups.google.com/group/ode-users/browse_thread/thread/50cba88cf73a5f37/6417b209750ce94a?lnk=gst&q=GIMPACT#6417b209750ce94a

Discussion

  • Tilmann Zaeschke

    Tilmann Zaeschke - 2010-03-04

    Patch for GIMPACT/heightfield collision

     
    PatchForGimpactTrimeshByTilmann.patch

  • Oleh Derevenko

    Oleh Derevenko - 2010-03-28

    It's hard for me to verify if the changes are all correct. :( Well, maybe I'm just not in a good mood for that. ;) In any case I would prefer (and, I'm sure, everyone else would) some more local fix to the problem.
    Well, it's actually the implementation defect of GIMPACT if it stores copies of attributes of other objects and changing main code because one of trimesh collision libraries has internal problems is not the best approach.
    Actually, the best would be eliminate the rotation altogether from the exeisting code. Since every heightfield tile is a plane and plane normal is easily known from its parameters it would be the best to just account for plane orientation in actual collision checking formulaes, with applying actual rotation neither to shape nor to the heightfield object.

     

  • Tilmann Zaeschke

    Tilmann Zaeschke - 2010-03-29

    First, I forgot to mention that it the old behaviout can be restored by commenting out line 28 in heightfield.cpp ("#define dUSE_ORIENTED_BB").
    We discussed several solution on the mailing list (http://groups.google.com/group/ode-users/browse_thread/thread/50cba88cf73a5f37/07e40dfd5602ee51?lnk=gst&q=gimpact+problem#07e40dfd5602ee51).
    In my opinion is that having an internal AABB is not an internal problem of some included library. The problem is that the library is used in the wrong way (but I think that's besides the point anyway).
    Several solutions were discussed on this was the only that didn't meet any resistance back then, except that it involved by far the most work.
    I fully agree with you that the chosen solution has the downside of involving many changes, hence being difficult to test. The argument to do it this way was back then that it allows using third part geoms that manage their own AABB. In addition it improves encapsulation, which I think is always a good thing.
    The idea behind rotating the geom instead of the planes is probably that the bounding box check is very efficient with horizontal planes. Rotating and trimming the planes could in theory be very fast if the heightfield would always be horizontal (or vertical), but unfortunately it allows for arbitrary rotation matrices.

    I have spent considerable time implementing and testing the current solution, and back then nobody disagreed with it. However I'm happy to resume the discussion and find a better solution, if there is one.
    Would you agree that we should continue the discussion on the mailing list visible for everyone?

     

  • Daniel K. O.

    Daniel K. O. - 2014-02-04
    • status: open --> closed
    • Group: --> None
     

Log in to post a comment.