[ODE] Trimesh-trimesh and dGeomTriMeshDataSet

[Peter Kyme]

Dominic Jackson wrote:
> Probably a bit off topic and highly unlikely to relate to the actual
> problem, but am a bit surprised that you do this
> 
> const dReal *rot = dBodyGetRotation(m_body);
> const dReal *pos = dBodyGetPosition(m_body);
> const double trans[16] = {rot[0], rot[1], rot[2], pos[0],
>                            rot[4], rot[5], rot[6], pos[1],
>                            rot[8], rot[9], rot[10], pos[2],
>                            0, 0, 0, 1.0 };
> 
> I would personally always opt for consistency and define
> 
> const dReal trans[16] = ....
> 
> Obviously if you decide to define dReal as float elsewhere then this
> could cause ( mainly compiler warnings I would expect ) some problems.
> 

I was of the impression that the transform array had to be 16 doubles, 
and since I'm using single precision in ODE, I declared it explicitly as 
such.

> Anyway, I am not clear on how you are generating your trimeshes - is it
> possible that you are generating half of them clockwise and half
> anti-clockwise or similar - perhaps something like that might cause the
> problem you are describing ?
> 

I'm pretty sure the trimeshes are being generated consistently. I've 
checked the normals generated in dCollideTTL and they seem to be 
correct. Thanks anyway.

More info: For case A below, the contacts generated look like this:

contact pos:    0.5, 0.499713, 0.5
contact normal: 0, 1, 0
contact depth: 0.000286818

for case B, the contacts are:

contact pos:    0.5, 0.5, 0.5
contact normal: 0, -1, 0
contact depth: 0.000286818

where the contact position is y = 0.5

> Cheers
> 
> Dominic jackson
> 
> 
> 
> -----Original Message-----
> From: Peter Kyme [mailto:pk at dneg.com] 
> Sent: 21 June 2005 13:09
> To: ode at q12.org
> Subject: [ODE] Trimesh-trimesh and dGeomTriMeshDataSet
> 
> Hi All,
> 
> I'm having some issues with trimesh-trimesh collisions and I'd 
> appreciate it if someone could point me in the right direction.
> 
> The problem manifests itself as reversed contact normals being returned 
> from dCollide for half of the collisions. I have a collection of simple 
> tests, and half of these will fail (interpenetration of geoms). If I 
> manually reverse the contact normals, the other half will fail.
> 
> For example, the following system works fine:
> 
>    +--+
>    |  |
>    +--+
> +------+
> |      |
> |      |
> +------+
> 
> Here the larger box is static, and the smaller box collides with it as 
> expected. However if the situation is reversed:
> 
> +------+
> |      |
> |      |
> +------+
>    +--+
>    |  |
>    +--+
> 
> The larger box completely penetrates the smaller (static) box, unless I 
> reverse contact normals.
> 
> I am of the impression this could be related to incorrectly calling the
> dGeomTriMeshDataSet( TriMeshData, TRIMESH_LAST_TRANSFORMATION ...
> function.
> 
> Currently my main simulation loop looks like this:
> 
> loop {
>     space->collide()
>     for all bodies{ setTrimeshLastTransform() }
>     dWorldStep()
>     space->cleanupCollisions()
> }
> 
> and setTrimeshLastTransform() looks like:
> 
> const dReal *rot = dBodyGetRotation(m_body);
> const dReal *pos = dBodyGetPosition(m_body);
> const double trans[16] = {rot[0], rot[1], rot[2], pos[0],
>                            rot[4], rot[5], rot[6], pos[1],
>                            rot[8], rot[9], rot[10], pos[2],
>                            0, 0, 0, 1.0 };
> dGeomTriMeshDataSet( meshId, TRIMESH_LAST_TRANSFORMATION, (void *) trans
> );
> 
> I'm using a stepsize of 0.005, maximum contacts of 80, and I'm letting 
> ODE calculate the trimesh normals.
> 
> Does anyone have any ideas what might be going wrong?
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________
> 
> __________________________________________________________________________________________________________________________________________
> Information contained in this e-mail is intended for the use of the addressee only, and is confidential and may be the subject of Legal Professional Privilege.  Any dissemination, distribution, copying or use of this communication without prior permission of the addressee is strictly prohibited.The views of the author may not necessarily constitute the views of Kuju Entertainment Ltd. Nothing in this email shall bind Kuju Entertainment Ltd in any contract or obligation.
> 
> The contents of an attachment to this e-mail may contain software viruses which could damage your own computer system. While Kuju Entertainment has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening the attachment.
> 
> __________________________________________________________________________________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> _________________________________________________________________________________________________________________________________________
>