[ODE] Still Spheres Vs Trimesh at Triangle Edges

Petr Sovis petr at preality.com
Tue May 2 00:13:26 MST 2006 

The only way to handle sphere - tris contact manifold generation properly is 
to sort contacts (prior to sphere) from deeper penetration to shalow 
penetration and then cut off contacts lying behind contact planes as 
follows:

1) sort contact prior to penetration depth => 1..n contact points
2) for i = 1..n, take i-th contact and cut off all contact points (i + 1 .. 
n) lying behing i-th contact plane (point & normal). there should be some 
epsilon to take care about coplanarity.

Petr

P.S. this work for fastcar sim, although raycasts are more reliable

----- Original Message ----- 
From: "Jaroslav Sinecky" <sinecky at telefonica.net>
To: "Ettore Pancini" <ekt at libero.it>
Cc: <ode at q12.org>
Sent: Tuesday, May 02, 2006 8:31 AM
Subject: Re: [ODE] Still Spheres Vs Trimesh at Triangle Edges


> 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 :(
>
> Cheers,
> Jaroslav
>
> 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
>>
>>
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>

More information about the ODE mailing list