NormandC wrote: ↑
Fri Jan 19, 2018 3:33 am
Please read again what Quaoar wrote. It checks BOPs already applied, not ones that may or may not be possibly applied. It is to be used after a BOP, not before.
No! Quaoar is telling you how it was designed to be used by the developers, not how it has to be used. The bopcheck doesn't have any knowledge of how the shape was constructed, an imported step is the same as a result from a previous boolean operation.
Quaoar wrote: ↑
Fri Jan 19, 2018 6:23 am
Let me expand a bit on how we use these BOP checkers in OCC. Boolean algorithm is probably the most tricky part of the kernel. Like any other geometric algorithm it sometimes fails as no brep tool is perfect. Failures of BOPs are most often caused by tangent/overlapping conditions between the operand shapes, and also by tolerances whose presence contributes a lot to the complexity of computations.
We often get bug reports on BOPs and we often discover those problems with overlappings and tolerances. To make our life easier we have developed those BOP checkers as they allow us easily diagnose the conditions of failure. It would be safe to say that those checkers are not designed for users of OpenCascade as they may produce lots of false-positive errors. You have to be a developer of BOPs to get some useful info out of those checkers.
For general-purpose validity checks we have another tool which is BRepCheck_Analyzer. As rule of thumb, if BOP fails for operands which are Ok w.r.t. this latter Analyzer, then OCC is to blame.
Few years ago we considered rewriting Analyzer to absorb useful checks from BOP diagnostics. But that"s a long shot which would likely never lead anywhere. BOP checkers are too severe and slow. Most algorithms can survive in presence of geometric "defects" reported by the BOP checkers including BOP themselves. Applying those severe checkers to all inputs in any conditions will give you a frustrating output that half of your models are "crappy" while they are not.
I am sorry. This is my fault. When I added the bopcheck to the check geometry command, I made a post describing that the implications of the results were to be open for interpretation and only relative to the bop operations. The uncertainty combined with performance, pushed me to make it an option that needed to be turned on by the user, in a hope there would be a conversation laying out the implications. Unfortunately it evolved into 'turn on the bop check'. I am guilty as much as anybody else for that. As always, thanks for adding something beyond opinions.
You mention that bop is probably the trickiest part of the kernel, I would also argue that it is also the most important. Consider a CAD user that has put in 40hrs into a design and has reached a point where he can't get his model through a needed boolean operation. He/She traces the problem to something done 5hrs into the design. Now there is potential for a good amount of work to be thrown away. If this individual had known of these conditions, maybe there would have been a different workflow to avoid these problems. As a CAD user in a production environment, I need to complete my models, so I want to know what geometry/topology the bop operations don't like as soon as it exists. These are my reasons for enabling the bopcheck.