[ODE] TriMesh

[Gopi Prashanth]

if (b1 && b2 && dAreConnectedExcluding(b1, b2, dJointTypeContact))
    return;

What will that statement do if any one of the bodies is null... which it is
in your case... it is an escape scenario for anything against the mesh...
fix that and you would have some solution.


-----Original Message-----
From: TongKe Xue [mailto:xue at cs.stanford.edu]
Sent: Wednesday, August 17, 2005 2:55 PM
To: Gopi Prashanth
Cc: 'tkxue at stanford.edu'; ode at q12.org
Subject: RE: [ODE] TriMesh


#1 The TriMesh does NOT have a body associated with it.
    I want it to represent a static object, like terrain.
    If I recall correctly, not attaching it to a body is
    equivalent to attaching it to body 0, which causes it
    to not move. This worked when I wanted to create a stair
    step with a box -- I created a box Geom with no Body
    attached to it. Are Trimeshes special cases?

#2 For the contact loop, I set the maximum to be 10.
    2-3 are generated every time nearCallback is called.

    Right now, it just falls. In the past, there has been
    situations thwere it intertwines a bit, then the tail
    falls through, then the middle of the body wavers a bit
    and then fall through.

Thanks,
--TongKe

On Wed, 17 Aug 2005, Gopi Prashanth wrote:

> Question 1: Does your Tri Mesh have a body associated with it, if not then
> it will never get in your loop.
> Question 2: How many contacts are being generated in the loop. Does the
> object just fall or does it interwine and fall?
>
> Thanks,
> Gopi
>
> -----Original Message-----
> From: TongKe Xue [mailto:tongke at gmail.com]
> Sent: Wednesday, August 17, 2005 2:30 PM
> To: ode at q12.org
> Subject: [ODE] TriMesh
>
>
> Hi,
>
>  I have this serpentine robot I'm simulating in ODE. It's just a
> bunch of boxes connected together by hinges. I'm having some problems
> with having it stay on tri-meshes (as opposed to falling through).
>
> My nearCallbackk looks like:
>
> void nearCallback (void *data, dGeomID o1, dGeomID o2)
> {
>  int i,n;
>
>  dBodyID b1 = dGeomGetBody(o1);
>  dBodyID b2 = dGeomGetBody(o2);
>
>  if (b1 && b2 && dAreConnectedExcluding(b1, b2, dJointTypeContact))
>    return;
>
>  const int N = 10;
>  dContact contact[N];
>  n = dCollide (o1,o2,N,&contact[0].geom,sizeof(dContact));
>  if (n > 0) {
>    for (i=0; i<n; i++) {
>      contact[i].surface.mode = dContactSoftERP | dContactSoftCFM|
> dContactApprox1;
>      //contact[i].surface.mode = dContactSlip1 | dContactSlip2 |
> dContactSoftERP | dContactSoftCFM| dContactApprox1;
>      contact[i].surface.mu = dInfinity;
>      contact[i].surface.soft_erp = 0.2;
>      contact[i].surface.soft_cfm = 0.001;
>      contact[i].surface.bounce = 0.01;
>      dJointID c = dJointCreateContact (G_simul_world,
> G_simul_contactgroup, contact+i);
>      dJointAttach (c,b1,b2);
>    }
>  }
> }
>
>
>  What works:
>    * snake robot does NOT fall through the floor (dPlane)
>    * snake robot does NOt fall through boxes (dBox)
>
>  However, now that I play with tri-meshes, I have the following problem:
>    * in some positions (like 0, 0, 0) if I drop the snake, it lands
>      on the trimesh, takes it's contour, and everything is good.
>    * however, if I move the tri-mesh around a bit, using
>      dGeomSetPosition, the snake will fall right through the trimesh
>
>  The entire trimesh is constructed in the same way, as follows:
>
>  for(int i=0; i<width; ++i)
>    for(int j=0; j<length; ++j)
>      locs[i][j] = some_random_value();
>  smooth(locs, window, iterations);
>
>  for(int i=0; i<width; ++i)
>    for(int j=0; j<length; ++j) {
>      vertex[i*length+j][0]=i;
>      vertex[i*length+j][1]=j;
>      vertex[i*length+j][2]=locs[i][j];
>    }
>
>  // and then I construct triangles for the following pairs:
>
>  (i, j) (i, j+1), (i+1, j)
>     and
>  (i+1, j) (i, j+1), (i+1, j+1)
>
>  for i<width-1; j<length-1;
>
>  // basically, I create a grid, and chop each square into two
>  // triangles
>
>  this Trimesh also displays properly in ODE
>
>  things I've tried:
>  * tuning the step size down to 0.001 (for time step size)
>  * tuning the CFM down to 0.000001
>
>  neither of which helped
>
>
>
>  Any ideas what might be going on?
>
> Thanks,
> --TongKe
>
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>