greetings!

still trying to get a reliable triangle ray intersect working, but to no avail. any guidance greatly appreciated! i’m trying to determine from a mouse pick, which tirangle in the scene is closest to the camera location, and the point in space where the ray intersects the plane of the triangle. this is, of course, essential to do terrain following as well as triangle mouse picking in the scene.

first i tried using TrianglePickResults to narrow down to a small set of triangles, subsequently processed with a straight implementation of the MollerTrumbore algorithm:

http://www.acm.org/jgt/papers/MollerTrumbore97/

this however did not work as i expected. rather, the algorithm determined that the triangles in question were actually NOT intersected by the ray created via mouse pos and camera location.

so then i tried to simply iterate each and every triangle in my target geometry, testing each one with MollerTrumbore, trying to find the closest triangle to the ray origin. in this case, no matter where i moved the mouse, it always returned the same triangle, with a variable distance from that triangle.

is there something i am missing regarding how triangle vertices are stored? are their coords global or local (i tried applying the mesh’s translation to the vertices to no avail)? is the fact that the geometry is scaled after it is loaded from a model file mucking things up?

does anyone have a proper triangle ray intersect working in jME???

thanks,

j

Triangles are defined by 3 indices into the triangle array for the mesh. Each point is a Vector3f for that mesh in Local Coordinates. So, you’ll have to convert these points by the world scale, world translation and world rotation to project them into the world coordinates before testing for collision.

Hope that helps.

as usual, it was not much longer after i reached the frustration point sufficient to post a message, that i figured it out, and the algorithm now functions correctly

so, is there any reason why jME does not support this type of triangle picking (or does it)? it seems to perform reasonably well on a 600 triangle search set. i return the closest triangle index, it’s parent mesh, the distance to the closest triangle, and the cartesian coord on the triangle plane where the ray intersects.

j

We stopped at Triangle collision/picking simply because that was all that we wanted at the time. However, that’s not to say we wouldn’t like pixel perfect collision/picking as well. So, that’s definately something that would be a welcome addition (perhaps PixelCollisionResults PixelPickResults, etc).

1. is there a way to quickly retrive just the triangles of a given mesh currently being rendered (i assume there is, otherwise how would you get the triangle count in fps.print). in other words, the "on screen" triangles.

Well, the way the picking works, it quickly throws away all elements of the scene that don't matter (including the nodes that are not on the screen) and then some. So, for instance, if you render rootNode and then call rootNode.pick(...) you will be testing pretty much the same nodes that have been rendered (and most likely fewer), as the ray intersection is able to throw out more nodes faster than the frustum culling. (it's an easy test).

2. is there a way to quickly return triangles in a bounding volume (i assume again there is, through BoundingPickResults).

Do you mean the triangles of the bounding volume itself? If so, bounding volumes don't have triangles as they are not part of the scene. They are not concrete.

if you know of any demo code, would be appreciated...

jmetest.intersection.TestOBBPick and jmetest.intersection.TestOBBTree are triangle accurate picking and collision.

jmetest.intersection.TestCollision and jmetest.intersection.TestPick are bounding volume accurate.