OCCT can take a long time to check for overlaps between some solids, e.g. minutes.
the observed behavior is that the overlap_checker will run for a long time, with only a single thread active at the end. this is because all other pairs have been processed, and it's just waiting on a single errant pair for the program to stop. I can't decide if we should just wait, but there are so many times when I see this that it seems worth while looking into.
I think I might be able to use Message_ProgressIndicator::UserBreak() to do this cleanly (set via BOPAlgo_Options::SetProgressIndicator()) to report (for human checking in a CAD package). stopping pairwise checks that take "too long" (e.g. 5 minutes) would be useful for batch checking many files
e.g. my script for checking all of Colin's files aborts if the overlap checking program runs for more than 10 minutes, but for large files this might be wrong as it could still be making useful progress
OCCT can take a long time to check for overlaps between some solids, e.g. minutes.
the observed behavior is that the
overlap_checkerwill run for a long time, with only a single thread active at the end. this is because all other pairs have been processed, and it's just waiting on a single errant pair for the program to stop. I can't decide if we should just wait, but there are so many times when I see this that it seems worth while looking into.I think I might be able to use
Message_ProgressIndicator::UserBreak()to do this cleanly (set viaBOPAlgo_Options::SetProgressIndicator()) to report (for human checking in a CAD package). stopping pairwise checks that take "too long" (e.g. 5 minutes) would be useful for batch checking many filese.g. my script for checking all of Colin's files aborts if the overlap checking program runs for more than 10 minutes, but for large files this might be wrong as it could still be making useful progress