I’ve been using OptiX Prime to accelerate my finite element code’s radiative heat transfer capability, and I’ve been really impressed with its performance. Another very expensive part of my simulations is the determination of mesh-to-mesh contact regions, and I was interested in trying to use OptiX to help with this too.
I was thinking of having each triangle on the surface mesh trace a handful of rays from its current location to where it is predicted to be at the next time step, and finding which rays intersect, and where. However, the mesh geometry is actually a moving target (i.e. it is deforming during the time step too), and I wasn’t sure what the best way would be to handle that.
I had thought about generating a sequence of intermediate-configuration meshes, and intersecting rays against all of them to get an idea of when/where each ray hit, but it seems like the rays would just report collisions with the triangles they originated from.
Does anyone have input on potential ways (masking, features in OptiX instead of OptiX prime, etc), to leverage ray tracing for collision detection?
If the method with the intermediate configuration meshes is precise enough, it would be easy to ignore hits on the same triangle you started the ray off with OptiX, not so much with OptiX Prime.
That could be done similarly to one method for self-intersection avoidance.
Simple case first: The mesh has no instances, means all triangles are unique and as such you can mark them with a unique identifier.
For example, I’m using indexed triangles with uint4 indices where the .xyz components contain the triangle vertex indices and the .w component contains a unique identifier.
Use the same unique numbering in all your intermediate meshes (assuming the topology doesn’t change otherwise this method isn’t applicable),
add an uint attribute to your intersection program which returns that unique identifier,
add an uint field to your per-ray payload,
fill that field with the identifier you started your ray from, and
add an any hit program which ignores the intersection if the current identifier attribute is the same as the one in the per ray payload.
Now if your closest hit program is ever invoked, that means the probe ray has hit another triangle in that timestep and you could calculate the intersection distance and if needed also figure out which other triangle was hit because you have the unique identifiers.
I have a question about the kind of movement. I assume with the finite element topic involved the meshes actually deform and not just shift as a group? So a different transformation per triangle?
Then the above method would actually work the easiest, though depending on the required precision and mesh size this could get big.
Thanks for the input! It sounds like there’s a lot more flexibility in the OptiX workflow (compared to Prime), so I’ll definitely try out this approach.
Here’s a little 2D example of the kind of hit I was trying to describe: http://i.imgur.com/p4LTtLJ.gif (moving points hitting moving facets)
However, it occurs to me now that the red point in the gif is actually the solution to a weakly nonlinear system, so there’s probably no closed form solution that could be put in a hit program. For the near future, I’ll just look into subdividing the timestep and using your approach.
And for finite element meshes, every vertex is free to move independently, but the size of each scene is usually pretty manageable.
