Tool vanishing problem when drilling

Hi all:
As you see in videos, it appears that the error happened when the collision occurred between the tool and the unclosed part of model. In order to avoid that, i’m going to setup a check mechanism when generating surfaceMesh. Is there any way to inspect closure of surfaceMesh? or any other way to avoid this problem.


What kind of obejcts are colliding here (Mesh/Mesh, Mesh/Capsule …)? The tool disappearing is usually an indicator for Nan somewhere in the solution. If it’s mesh/mesh check that the collision you’re getting isn’t a ClosedSurfaceMesh... solution. In general hitting the edge of an open face should do the “right” thing.

VTK has a hole filling algorithm available, this might help.

Hi Harald:
what i use as solution is ImplicitGeometryToPointSetCCD used in RigidObjectLevelSetCollision. would you please explain more about “an indicator for Nan somewhere in the solution”? like how to check this value or some examples to figure out what it happen. Thanks!

You should try and close your model mesh before turning it into a level set.

In general NaNs can occur when an invalid computation (amongst others divide by 0) is performed. Any expression that involves a NaN value will in turn produce another NaN value. While we try and guard for that there are always cases that can slip through. Finding the point of origin can be a long path, in general it involves spreading checks throughout the engine until one hits the calculation that produces the error and then trying to prevent the case or correct the code there.

As the rigid tools is disappearing my first guess is that there is a NaN in that tool transform, to start you can check in [imstkRigidObject2.cpp](] lines 45, and 49 via m_rigidBody->getPosition().hasNaN() and m_rigidBody->getOrientation().coeffs().hasNaN(), hasNaN() is a function defined on matrices by the Eigen library. If that test is positive i.e. hasNan() returns true when the tool disappears, you will start having to figure out where the appropriate value gets written from, by finding writes to m_pos and m_orientation of the m_rigidBody, probably in the collision handler.