This is a Matlab wrapper for OPCODE, which is a collision detection
or ray casting library for triangular 3D meshes.
OPCODE uses a couple of different aabb trees to store the mesh and this is
a pretty simple wrapper for one of the trees.

Nice thing about opcode is that it allows for deformable meshes,
meaning that you can update the mesh while it is stored in the tree,
which is much faster than what it takes to rebuild the aabb tree.

To get the actual 3D coords, you can also do
Qhit = repmat(1-B(2,:)-B(1,:),3,1).*v(:,f(1,T)) + ...
repmat(B(1,:),3,1).*v(:,f(2,T)) + ...
repmat(B(2,:),3,1).*v(:,f(3,T));
where B = bary(:,hit), T = trix(hit),
which gives you the coordinates at the intersected points.

To update the mesh with a new set of vertices (as in deform the mesh):
tree.update(vnew);
vnew : 3 x nv
vnew must be the same size and the original set of vertices.
The topology of the mesh cannot change.

To delete the tree (which is actually done automatically by Matlab when the variable is cleared):
tree.delete();

To compile, go to ./src_matlab
and run mexall.m
which compiles the mex code and copies it to ./matlab
(I compile it against everything in opcode, so it's a bit slow.)

Fixes from the previous version:
Fixed compile issues for Win64 by removing all of the assembly code.
You don't need to normalize the direction vectors anymore.
It also returns the actual points now instead of just the barycentric points.

In all cases just leave the code below #else (this is in vanilla C++) that does the same work without any incompatibility with win64.

Finally, unfortunately the returned d (matrix of distances) returns wrong values that seem to be scaled or shifted by the number of rays (vectors from-to), even if this vector is normalized as suggested by Vipin.
Vipin can you check and fix this please.

For it to be perfect I suggest returning the correct 'd' matrix, not needing the normalization step in Matlab and returning the intersection points(Q matrix) from the Mex function. That would be nice.

You had to normalize the direction (to - from) and I had gotten the calculation for the points Q wrong. I will upload a version eventually so you don't have to normalize the direction. Btw, here is an example that works:

Fixed compile issues for Win64 by removing all of the assembly code.
You don't need to normalize the direction vectors anymore.
It also returns the actual points now instead of just the barycentric points.

19 Jun 2014

1.2

Fixed compile issues for Win64 by removing all of the assembly code.
You don't need to normalize the direction vectors anymore.
It also returns the actual points now instead of just the barycentric points.