[ODE] Still Spheres Vs Trimesh at Triangle Edges
Jaroslav Sinecky
sinecky at telefonica.net
Tue May 2 00:39:44 MST 2006
Ehm, sorry. I have just realized that MERGECONTACTS merges all trimesh
contacts into one, so it actually is "some kind of postprocessing".
Still you could try some other merge strategies, for example keeping
just the contact with deepest penetration and throwing out all others
seems a good one for this case.
Jaroslav Sinecky wrote:
> 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