# Not even sure how to title this... contact point within a triangle

I’m in need of getting a relative contact point within a triangle. The contact point is results from a ray cast. For some reason my brain is complete drawing a blank here…

I’m trying to rebuild the contact point as texture coordinates… soooooo, basically:

1. Get the triangle’s indices
2. Grab the relative tex coords from the mesh
3. Do a little min/max…
4. Make a little love…
5. Get down tonight.

Where I am drawing a mental blank is, the contact point returned in the collision results looks to be world coordinates?? I’m looking for a normalized vector relative to the triangle.

Any brainiacs out there have a clue as to how I might proceed with this? Maybe it’ll hit me… but my brain is sorta spinning on a million things right now. This one is nagging at me… but… anyways.

I’m guessing it probably is subtracting the center point from each vert… doing the same for the contact point, as a start anyways.

In order to compute the collision point in world space jME3 first computes barycentric coordinates of the collision on the triangle and then uses them to compute the world coordinates based on the vertex positions. The same concept can be applied to compute other interpolated data such as texture coordinates, colors, normals, etc.

Currently though, jME3 doesn’t expose this information in the collision result object (but it wouldn’t be a bad idea to do so).

Well… at least I know I am not crazy for wanting this info. It seems to be part of the collision results returned for ray casting in Unity3D… but I am finding no other useful info on the subject.

Let me break down what I have again…

[java]
Geometry geom = closest.getGeometry();
int triIndex = closest.getTriangleIndex();
geom.getMesh().getTriangle(triIndex, indices);
FloatBuffer tc = geom.getMesh().getFloatBuffer(VertexBuffer.Type.TexCoord);
uv1.set(tc.get(indices[0]*2), tc.get(indices[0]*2+1));
uv2.set(tc.get(indices[1]*2), tc.get(indices[1]*2+1));
uv3.set(tc.get(indices[2]*2), tc.get(indices[2]*2+1));

``````float x = Math.min(uv1.getX(), uv2.getX());
x = Math.min(x, uv3.getX());
float w = Math.max(uv1.getX(), uv2.getX());
w = Math.max(w, uv3.getX());
float y = Math.min(uv1.getY(), uv2.getY());
y = Math.min(y, uv3.getY());
float h = Math.max(uv1.getY(), uv2.getY());
h = Math.max(h, uv3.y);
``````

[/java]

This gives me the range for both u and v of the triangle collided with.

So, now I am stuck with knowing the possible ranges and a collision point that does not relate to this in any capacity. Ideas?

@Momoko_Fan said: In order to compute the collision point in world space jME3 first computes barycentric coordinates of the collision on the triangle and then uses them to compute the world coordinates based on the vertex positions. The same concept can be applied to compute other interpolated data such as texture coordinates, colors, normals, etc.

Currently though, jME3 doesn’t expose this information in the collision result object (but it wouldn’t be a bad idea to do so).

Ooops… you posted this while I was brain dumping. It would be awesome if this (or at least the barycentric coordinates) were available =)

Soooo. is there anyway to determine the information based on the world coords?

Well, you could convert your corrdiantes to local ones first,
then you can get the triangel from the collision, and adjust the collision point so it lies perfectly on it (eg accuracy problems, contaactes with overlapping bodies ect.) by doing a point to plane closest line, and the the crosspoint of the line and the plane.
Then you can get the uv for ech of the three vertexes,

You search u and v for a known x,y,z and you know for each of the triangles x,y,z and u,v
So you have 4 formulars with 2 unknown wich can be solved by a gaussian algorithm thingy.

/Who would have thought that school math was ever usefull again XD )

@Empire Phoenix said: Well, you could convert your corrdiantes to local ones first, then you can get the triangel from the collision, and adjust the collision point so it lies perfectly on it (eg accuracy problems, contaactes with overlapping bodies ect.) by doing a point to plane closest line, and the the crosspoint of the line and the plane. Then you can get the uv for ech of the three vertexes,

You search u and v for a known x,y,z and you know for each of the triangles x,y,z and u,v
So you have 4 formulars with 2 unknown wich can be solved by a gaussian algorithm thingy.

/Who would have thought that school math was ever usefull again XD )

Heyas!

Any chance you could explain this a bit further? I have tried quite a few approaches so far with no success and it seems that you feel you got this one If so! I’m all ears because, because so far I am stumped.

Step 1: take original ray
Step 2: take triangle original ray found.
Step 3: manually reperform the collision against just that triangle getting all the info you want right there. Cut and paste the math as necessary (though I don’t think it’s necessary).

@pspeed said: Step 1: take original ray Step 2: take triangle original ray found. Step 3: manually reperform the collision against just that triangle getting all the info you want right there. Cut and paste the math as necessary (though I don't think it's necessary).

This thought had occurred to me, I was just hoping that the relative info was provided and I was missing it. Now for a question concerning best way to do this over and over again without making it a performance issue? Create a mesh and alter the existing buffer for the current triangle? Just create the mesh needed each time?

?

I’m confused. The collision result tells you the triangle. Why do you have to hit the whole mesh again?

Extract the single triangle’s data and do what the collision stuff does at the very very very bottom of what it’s doing.

Actually, it could be that you have some cutting and pasting to do after all. (Note: found this in only 1 minute of google code clicking)

It doesn’t seem to expose any of the info outside of the method but the math is all there.

Edit: and the utility of this is predicated on whether or not the original statement that the collision code already has the info is correct. I haven’t unwrapped the math to verify… but that’s the code that does triangle collisions.

1 Like
@pspeed said: Actually, it could be that you have some cutting and pasting to do after all. (Note: found this in only 1 minute of google code clicking)

It doesn’t seem to expose any of the info outside of the method but the math is all there.

Edit: and the utility of this is predicated on whether or not the original statement that the collision code already has the info is correct. I haven’t unwrapped the math to verify… but that’s the code that does triangle collisions.

As retarded as this is, I had trouble finding this. I apparently was not searching for the correct thing, I was looking at spatial/geometry/node.collidesWith, CollisionResult, CollisionResults and just getting more and more lost. Thanks for this, it’s just what I was looking for.

@pspeed said: ?

I’m confused. The collision result tells you the triangle. Why do you have to hit the whole mesh again?

Extract the single triangle’s data and do what the collision stuff does at the very very very bottom of what it’s doing.

Oh… I wasn’t referring to hitting the entire mesh… I was assuming that I would have to re-cast the ray against a mesh containing the single triangle from the original collision, which was probably an incorrect assumption on my part.

Maybe JME can provided a switching system for selecting other relevant information for collision results? After looking at the Unity list, I can see all of these being useful in different circumstances.

I think I am getting a bit closer to what I actually need, but still a bit (or more than a bit) confused. Can someone correct me if I am going about this the wrong way?

1. I have a triangle verts transformed to world coords.
2. I have the uv coords associated with each vert.
3. I have the x,y,z distances of the contact point from each vert.

Where I am lost is how to take this info and determine the closest uv coords. I know these are the components needed… can someone push me in the correct direction with the above info? I have no clue why this is not registering with me, but… unfortunately, it isn’t =)

@pspeed I looked through intersects() but not sure what the float value that is returned represents. ?? The JavaDoc info about it isn’t very clear.

Here is a quote from the JavaDoc info:

“”

It didn’t help Any idea what this represents?

@t0neg0d said: @pspeed I looked through intersects() but not sure what the float value that is returned represents. ?? The JavaDoc info about it isn't very clear.

Here is a quote from the JavaDoc info:

“”

It didn’t help Any idea what this represents?

If you look at the method that calls it…

You can see that it is used as distance to the contact point.

1 Like

You have the world-space coordinates of the triangle and ray, hence you can use Ray.intersectWherePlanar() to compute barycentric coordinates. Once you have those, use them against the triangle’s texture coordinates to get get the intersection in terms of texture coordinates.

1 Like

@Momoko_Fan
I seem to be getting varying results from intersectWherePlanar. The Ray seems to calc a collision correctly, but if you move the cursor along the x or y axis of any triangle, the numbers stored in u(y) and v(z) should at least be linear, yes? This is not what is being returned. Am I missing a step here?

Can you give us an example? Like the 3 triangle your contactpoint and your actual vs your excpected result?