OPCODE crashes, can't get at trimesh data

[CodeBot]

Hello again,

I have a trimesh that I created and imported into ODE to use for
collision detection. when I call dCollide() between it and a Box, it
crashes deep inside OPCODE. I create the trimesh using
dGeomTriMeshDataBuildSingle(), which after that, I can get at the
triangle data using dGeomTriMeshGetTriangle(). It returns correct data
for each triangle in the trimesh.

On the other hand, deep inside OPCODE, it crashes inside a function
called TransformPoint() in OPC_Common.h. The data is coming from
OBBCollider::_Collide(const AABBNoLeafNode*) which grabs a pointer to
the triangles using the following line:

VertexPointers VP;
mIMesh->GetTriangle(VP, prim_index);

The VP variable ends up being uninitialized values, which makes me
wonder if I missed a step when creating my trimesh. That value is then
passed on to the previously mentioned TransformPoint() function, which
tries to act on garbage data.

I know the problem sounds complex, and any help on this matter is
greatly appreciated!! Thanks in advance!

-Mark

[Oleh Derevenko]

----- Original Message -----
From: "CodeBot"

> On the other hand, deep inside OPCODE, it crashes inside a function
> called TransformPoint() in OPC_Common.h. The data is coming from
> OBBCollider::_Collide(const AABBNoLeafNode*) which grabs a pointer to
> the triangles using the following line:
>
> VertexPointers VP;
> mIMesh->GetTriangle(VP, prim_index);
>

VertexPointers VP - is a temporary storage used internally for type
conversions.

Also, there are no lines

> VertexPointers VP;
> mIMesh->GetTriangle(VP, prim_index);
>

in

void OBBCollider::_Collide(const AABBNoLeafNode* node)
{
// Perform OBB-AABB overlap test
if(!BoxBoxOverlap(node->mAABB.mExtents, node->mAABB.mCenter)) return;
TEST_BOX_IN_OBB(node->mAABB.mCenter, node->mAABB.mExtents)
if(node->HasPosLeaf()) { OBB_PRIM(node->GetPosPrimitive(), OPC_CONTACT) }
else _Collide(node->GetPos());
if(ContactFound()) return;
if(node->HasNegLeaf()) { OBB_PRIM(node->GetNegPrimitive(), OPC_CONTACT) }
else _Collide(node->GetNeg());
}

Oleh Derevenko
-- ICQ: 36361783

[Oleh Derevenko]

Well, it's inside of OBB_PRIM macro.
Anyway, it now looks as
VertexPointers VP; ConversionArea VC; mIMesh->GetTriangle(VP, prim_index,
VC); \

Update to latest revision first.

Oleh Derevenko
-- ICQ: 36361783

[Oleh Derevenko]

And VP is a tructure where pointers to triangle vertices are returned.

Oleh Derevenko
-- ICQ: 36361783

----- Original Message -----
From: "Oleh Derevenko" <od...@eleks.lviv.ua>
To: <ode-...@googlegroups.com>
Sent: 25 червня 2008 р. 17:10
Subject: [ode-users] Re: OPCODE crashes, can't get at trimesh data

>

[Oleh Derevenko]

Well, I would suppose you are creating trimesh with invalid data.

For example it could be, feeding floats of wrong size, mismatch of number of
triangles passed as parameter and actual index data size, any other
parameter inconsistencies, invalid library build, after all.

There are too many possible sources of problem. Try some simple trimesh and
evaluate the data you pass to trimesh creation calls to make sure the data
is correct.

Oleh Derevenko
-- ICQ: 36361783

[CodeBot]

The trimesh data is valid because I use it to draw the actual model in
openGL. The debugger gives me the following from within ODE:

mIMesh = const Opcode::MeshInterface *
mIMesh->mNbTris = 116
mIMesh->mNbVerts = 822
mIMesh->mTriStride = 12
mIMesh->mVertexStride = 12
mIMesh->mFetchTriangle = 0x01efff41
mIMesh->mTris = 0x09cf8028
- mIMesh->mTris->mVRef = 0x09cf8028 { 4277075694, 4277075694,
4277075694 }
mIMesh->mVerts = 0x021c5f68 {x=6.3000002 y=-5.5999999 z=0.00000000 }

If I print out the Vertex list, it shows me all of them. As if, when I
was feeding in the data, it did not realize that 3 Vertex values are
one triangle. I am guessing that is why the mTris->mVRef array is a
bunch of garbage characters.

I'm going to look up some examples on this, any info you guys can
provide would be a huge help!!

Thanks.
-Mark

[Jon Watte]

Chances are that you're building the triangle mesh with a function
(...Simple) that expects a dVector3, which is actually 4 floats, but
you're probably passing in an array of 3 floats per vertex. Use a
different function to build the trimesh data, or pass in data with a
stride of 16 to fix that.

Sincerely,

jw

[CodeBot]

I played around with the data and made it 4 floats long, padding the
last float with 0.0f. Unfortunately, this did not solve the problem.
ODE somehow cannot get at the triangles. I use the
dGeomTriMeshDataBuildSingle() function to plug in the data. All the
values are correct when they are plugged into that funciton (including
the 16 byte stride padding). If worse comes to worse, I'll use the
math functions myself to determine collisions.

Any thoughts on this matter are still appreciated!

Thanks.
-Mark

[Riemer v.d. Zee]

Could you show us some relevant code where you are actually trying to
build the trimesh?
I had problems with this function some while ago as well, however it
seemed to be a mistake at my side as I thought it asked for the
ammount of triangles instead of amm. vertices (maybe you are making
the same mistake?).

[CodeBot]

Here is the code. the variable vertexArr is an array of floats, which
are in [X, Y, Z, W] order, where the W parameter is not used. The
values in that variable and its indexArr counterpart have valid
values. The only thing is that they go out of scope once they are
plugged into ODE. I don't know if ODE copies them into its internal
structure or not? I assumed it did, could this be the problem?? Should
I use any of the callbacks that you can register with
dCreateTriMesh() ??

// Create a vertex buffer
body->trimeshID = dGeomTriMeshDataCreate();

// Build a Trimesh out of all of those vertexes
dGeomTriMeshDataBuildSingle(body->trimeshID, vertexArr, sizeof(float)
* 4, vertexSize, indexArr, indexSize, sizeof(int) * 3);

// Create a Trimesh
body->geomID = dCreateTriMesh(NULL, body->trimeshID, NULL, NULL,
NULL);

// Setup its parameters
dGeomSetQuaternion(body->geomID, ori);
dGeomSetPosition(body->geomID, params->position[0], params-
>position[1], params->position[2]);
dGeomSetData(body->geomID, body);


That is the extent of this function, all other lines of code in it are
declarations and a loop that pads the vertexes with the extra 4th
float value.

Thanks.
-Mark

[Daniel K. O.]

CodeBot escreveu:

> Any thoughts on this matter are still appreciated!

Try to use the bunny data from the demos. It's in bunny_geom.h.

--
Daniel K. O.
"The only way to succeed is to build success yourself"

[Riemer v.d. Zee]

>The only thing is that they go out of scope once they are
plugged into ODE. I don't know if ODE copies them into its internal
structure or not? I assumed it did, could this be the problem??

From the manual concerning the trimesh functions:
"No data is copied here, so the pointers passed into this function
must remain valid"

So basically this could be the problem yes.

[Jon Watte]

CodeBot wrote:
> I played around with the data and made it 4 floats long, padding the
> last float with 0.0f. Unfortunately, this did not solve the problem.
> ODE somehow cannot get at the triangles. I use the
> dGeomTriMeshDataBuildSingle() function to plug in the data. All the
> values are correct when they are plugged into that funciton (including
> the 16 byte stride padding). If worse comes to worse, I'll use the
> math functions myself to determine collisions.
>

Are you keeping the data live after the function? ODE does not copy the
data, only the pointers.

Sincerely,

jw