[ODE] Trimesh Sphere Interactions - how to break'test_trimesh.cpp'
Jaroslav Sinecky
jsinecky at tiscali.cz
Wed May 18 08:11:54 MST 2005
I have the same experience with mesh normals: don't seem to make any
difference. Changing the winding order was the only way to flip mesh
orientation.
Note: I only worked with sphere vs. trimesh collisions.
Jaroslav
> -----Original Message-----
> From: ode-bounces at q12.org [mailto:ode-bounces at q12.org]On Behalf
> Of Alex Green
> Sent: Tuesday, May 17, 2005 4:07 AM
> To: Megan Fox
> Cc: ode at q12.org
> Subject: Re: [ODE] Trimesh Sphere Interactions - how to
> break'test_trimesh.cpp'
>
>
> Thanks Megan, my stepsize is 0.01 and this or size of forces acting are
> not the problem as dCollide always returns zero when there is a problem.
> My triangles are from very small to a number of units in size and my
> object is about 2 units in size (spheres 0.4 units).
> You have given me my first clue that ODE uses counter-clockwise winding.
> This explains why I need to flip my mesh upside down. I was under the
> impression ODE used 'any triangle winding' or 'just a soup of
> triangles'. Why do box's sometimes work (ie wheels fall through
> clockwise mesh but body rests on top)?
> Also what is the effect of passing the normals? I pass the normals to
> buildSingle1() and I draw them for debugging, and my mesh looks like a
> nice little hedgehog with all the normals pointing upwards, but seams to
> have little effect on the behavior of the system.
> I will have a play with the winding and will try some of my experiments
> on test_trimesh.cpp. Anything interesting I will post.
>
> NORMALS: what does passing them to
> dGeomTriMeshDataBuildSingle1(, , , , , , ,normalsPTR) do?
>
> Any more detail on how ODE interprets winding order and collisions?
>
> Thanks again -alex
>
>
> Megan Fox wrote:
> > I dropped my trimesh heightmap in and it worked on the first try -
> > same code worked for arbitrary meshes as well, extremely solid. I
> > would be curious what you consider a small stepsize (try 0.01), and I
> > would also be curious what scale your forces are and what scale your
> > objects are vs the trimesh triangles.
> >
> > Winding Order - affects the generation of the normals from the trimesh
> > data. So, you need the same winding order on all your triangles (I
> > believe you need counter-clockwise winding order, but if that doesn't
> > work, just flip the mesh or try it the other way).
> >
> > Normals - I ended up letting ODE generate the normals for me. As I
> > said, they're influenced by the winding order of the polygon. If you
> > don't wind all the triangles in the same way, your normals will point
> > in different directions.
> >
> >
> >>From the results you're getting, it sounds as if your winding might be
> > problematic, but I really can't say going from just one email posting.
> >
> > -Megan Fox
> >
> > On 5/16/05, Alex Green <alexg at acfr.usyd.edu.au> wrote:
> >
> >>My simulation has a vehicle with spherical wheels and a trimesh terrain.
> >>I have had a lot of trouble getting consistent results with the trimesh
> >>sphere collisions. My stepsize is small and my erp is fine. Trimesh
> >>sphere collisions only work when the trimesh data is upside down and it
> >>depends on the shape of the trimesh. I have scoured the mail archives to
> >>no avail. For testing I output a txt file of every triangle in the
> >>trimesh data structure and they are: valid triangles, wound in the
> >>clockwise fashion and the normal points correctly. No Surprises.
> >>
> >>Today I ran some experiments with the trimesh example code. Try this:
> >>Take 'test_trimesh.cpp' turn the trimesh upside down by inserting the
> >>following lines after the trimesh is created:
> >> dMatrix3 triRot;
> >> dRFromAxisAndAngle(triRot, 0, 1, 0, M_PI);
> >> dGeomSetRotation(TriMesh, triRot);
> >> dGeomSetPosition(TriMesh, 0, 0, 1.0);
> >>
> >>Now drop a sphere on the trimesh, it falls straight through!! Drop a box
> >>it may work. To start with the following questions need to be put
> >>straight for all the new users using trimesh:
> >>
> >>What effect does the WINDING ORDER of the triMesh have on opcode/ode
> >>simulation?
> >>
> >>What effect does the SHAPE of the trimesh (eg. convex, concave) have on
> >>the opcode/ode simulation?
> >>
> >>What effect does including the NORMALS actually have in
> >>dGeomTriMeshDataBuildSingle1(, , , , , , ,normalsPTR)?
> >>
> >>What else do you need to know to get reliable trimesh/shpere collisions?
> >>
> >>When I sort this out I will be happy to write up a section in the WIKI
> >>on trimesh use. Many thanks -alex green
> >>_______________________________________________
> >>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