[ODE] Still Spheres Vs Trimesh at Triangle Edges

Jaroslav Sinecky sinecky at telefonica.net
Mon May 1 23:31:16 MST 2006

Well, I think I recognized that I also get little "jumps" when rolling 
over edges but it's small enough and hidden by contact "softness" (CFM) 
not to have really noticeable effect on handling.
I prefer to disable MERGECONTACTS because it's better for non-standard 
situations like sphere rolling over ground and at the same time touching 
a wall.

In my opinion the reason for this "jumps" is that you get doubled 
contacts when you're over the edge - one from each triangle, so one 
possible solution would be some kind of contact postprocessing.

Another options are
- try to play with CFM/ERP to make the jumps less noticeable
- wait for someone to implement trimesh preprocessing for trimesh-sphere

Really no more ideas :(


Ettore Pancini wrote:
> i still have problem mentione in the original post
> (spheres rolling over a trimesh jumps on every triangle edge)
> to me, turning off MERGECONTACTS gives worse results
> don't know why is the opposite for Sinecky.
> commenting all edge collisions in collision_trimesh_sphere.cpp
> (except interior region) works, but then I get a bad collision
> detection when the wheel goes over a sidewalk. this makes
> sense, though it becomes a half-solution.
> i don't have the knowledge to implement the preprocessed
> stuff for mesh-sphere collision
> what is my next best move?
> ----- Original Message ----- 
> From: "Jaroslav Sinecky" <sinecky at telefonica.net>
> To: "kurimail" <kurimail at arrakis.es>; <ode at q12.org>
> Sent: Monday, April 03, 2006 18:53
> Subject: Re: [ODE] Still Spheres Vs Trimesh at Triangle Edges
>> There is really an issue with contact depth in trimesh_sphere. There was a
>> change in depth calculation couple months ago. I didn't find it very good
>> because it introduced discontinuities. Now I have tried the svn trunk
>> version and found there was also a real bug introduced by this change 
>> (quite
>> difficutl to see at first glance but "side" value isn't actually distance 
>> of
>> sphere and triangle plane).
>> So I changed it to following: depth is calculated as triangle-sphere
>> penetration depth projected to triangle (=contact) normal. This is still
>> just aproximation but I find it better than previous two implementations.
>> Also reorganized a bit the code to pull out duplicate calculations. 
>> Checked
>> in svn trunk.
>> Still, you will get some oscilations when running over mesh edges (I get
>> them too, but they don't have noticable negative effect). This is because 
>> of
>> close contacts generated - one from each triangle, so implementing some
>> contacts postprocessing as suggested by Geoff is a good idea.
>> Also, if we implement the trimesh preprocessing for sphere collisions, it
>> could help a lot because all concave edges or edges between co-planar
>> triangles would be skipped from collisions (so for example rolling over
>> planar mesh should be as smooth as rolling over plane).
>> The last thing ... you could also play with #define MERGECONTACTS (at the
>> beginning of collision_trimesh_sphere.cpp). For me it works better to have
>> it turned off. In fact I  think it could be turned off by default because
>> both our test cases (test_trimesh and test_moving_trimesh) and most of 
>> real
>> world cases work better like that. With this merge turned on, if you drop
>> sphere in test_trimesh, it last ages to get still and also a sphere behind
>> bunny's ears has hard time finding stable position with one contact only.
>> Hope this helps,
>> Jaroslav
>>> -----Original Message-----
>>> From: ode-bounces at q12.org [mailto:ode-bounces at q12.org]On Behalf
>>> Of kurimail
>>> Sent: Saturday, April 01, 2006 12:09 PM
>>> To: ode at q12.org
>>> Subject: Re: [ODE] Still Spheres Vs Trimesh at Triangle Edges
>>> Mmm, the problem i am having is not about the normals, it looks like a
>>> problem with depth. Although the normal is always (almost) vertical for
>>> the wheels, the depth is higher on the triangle edges, so the wheel 
>>> jumps.
>>> I am going to try to comment the edge detection as suggested...
>>>> Hi,
>>>> I was going to reply with a note about this problem in regard to 1.0, 
>>>> so
>>>> I'm glad the issue came up.  I found this is a terrible problem with 
>>>> ODE
>>>> and trimeshes, and in fact been a little puzzled why nobody else has
>>>> ever seemed to complain about it.  I haven't had time to make up a
>>>> simple test showing the problem, but I'm sure a flat trimesh and 
>>>> rolling
>>>> sphere would clearly show what the poster was talking about.  I've 
>>>> found
>>>> the contact normals vary from the correct 90 degrees to clearly wrong
>>>> glancing angles that are almost horizontal.
>>>> In my case, I changed the trimesh collisions to always return the
>>>> triangle normal, rather than the "near to edge" direction.  In the 
>>>> cases
>>>> where the object should be pushed "out" at a non-normal direction, 
>>>> there
>>>> is a triangle neighbour which will do exactly that.  I didn't try
>>>> commenting out the edge collisions as suggested below, but that seems 
>>>> an
>>>> even better way to do it.
>>>> Ideally it needs a post-process of merging contacts, which I found
>>>> helped correctness and stability (there is nothing like conflicting
>>>> contacts to spin an object to infinity).  In my case it was done after
>>>> all object-object collision routines, to deal with the case of merging
>>>> contacts from different objects, such as from two trimeshes sitting 
>>>> next
>>>> to each other.  The merging in my case was to take all contacts at the
>>>> same position and lerp the normals.  As such, a sphere that hits a
>>>> trimesh with a box-edge feature would resolve from two contacts at 90
>>>> degrees into one contact at 45 degrees.
>>>> Geoff
>>>> kurimail wrote:
>>>>> Thanks for your answer!.
>>>>> The problem is that spheres rolling over a trimesh jumps on every
>>>>> triangle
>>>>> edge. I have a 4-hinged spheres car, and when a sphere rolls over 
>>>>> every
>>>>> triangle edge, a little jump occurs.
>>>>> As i sad, decreasing cfm solved a little the problem, but not all.
>>>>>> If you really think your problem would be solved if there were no
>>>>>> sphere-edge collisions (I doubt it because then your spheres should
>>>>>> sink
>>>>>> on
>>>>>> trimesh convex edges), you can eighter implement the preprocessed 
>>>>>> mesh
>>>>>> for
>>>>>> sphere collisions and submit it to svn (the more difficult way ;) or
>>>>>> take
>>>>>> much easier and faster way: have a look on GetContactData in
>>>>>> collision_trimesh_sphere.cpp and comment out all edge collisions (all
>>>>>> branches except region 0 - interior).
>>>>>> Anyway, as I say I doubt this would be a good solution. What
>>> exactly is
>>>>>> the
>>>>>> problem you are experiencing?
>>>>>>> -----Original Message-----
>>>>>>> From: ode-bounces at q12.org [mailto:ode-bounces at q12.org]On Behalf
>>>>>>> Of kurimail
>>>>>>> Sent: Friday, March 31, 2006 4:01 PM
>>>>>>> To: ode at q12.org
>>>>>>> Subject: [ODE] Still Spheres Vs Trimesh at Triangle Edges
>>>>>>> Hi again. I am still having troubles with spheres colliding at
>>>>>>> triangle
>>>>>>> edges. I don't know if the problem is the edge or the change from 
>>>>>>> one
>>>>>>> triangle to another.
>>>>>>> I looked at the preproccesing trimesh, but it is only for 
>>>>>>> ccylinders.
>>>>>>> I tried changing erp and cfm values. This helped, but not too much.
>>>>>>> I tried different scales, sizes, masses, mass shapes, etc... and
>>>>>>> nothing
>>>>>>> helped too much.
>>>>>>> I can accept any trick to avoid such jumps at triangle edge.
>>>>>>> Any help, please?
>>>>>>> Thanks in advance!
>>>>>>> _______________________________________________
>>>>>>> ODE mailing list
>>>>>>> ODE at q12.org
>>>>>>> http://q12.org/mailman/listinfo/ode
>>>>> _______________________________________________
>>>>> ODE mailing list
>>>>> ODE at q12.org
>>>>> http://q12.org/mailman/listinfo/ode
>>> _______________________________________________
>>> ODE mailing list
>>> ODE at q12.org
>>> http://q12.org/mailman/listinfo/ode
>> _______________________________________________
>> ODE mailing list
>> ODE at q12.org
>> http://q12.org/mailman/listinfo/ode 
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode

More information about the ODE mailing list