BOP checks

Have some feature requests, feedback, cool stuff to share, or want to know where FreeCAD is going? This is the place.
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
User avatar
sgrogan
Posts: 5425
Joined: Wed Oct 22, 2014 5:02 pm

BOP checks

Postby sgrogan » Fri Jan 19, 2018 3:12 am

NormandC wrote:
Fri Jan 19, 2018 2:57 am
sgrogan wrote:
Fri Jan 19, 2018 2:52 am
Perhaps I mis-understand. I thought BOP checks checked whatever geometry and identified areas a future BOP check would/might fail?
Sorry, but you misunderstand.

See Quaoar's reply above tanderson69's (Quaoar works for OCC):
Quaoar wrote:
Fri Dec 15, 2017 7:43 am
BOP check is a specific analysis tool dedicated to Boolean Operations. It is not a general validity checker for CAD models. E.g., you may want to run BOP checker in cases if you see that Boolean operation fails and you do not understand why. In such situation, BOP checker may give some hints like "this shape interferes this shape" (and then the question is what are we going to do with such models...). To conclude, BOP checker is a tool to check the quality of your operands with respect to OpenCascade Booleans only. Do not use it for general validity checks, it does not work for that.
Continued from here: https://forum.freecadweb.org/viewtopic. ... 20#p210287

I didn't want to steal the other thread.
I understand it's not a general tool, but isn't supposed to inspect the quality of one of the operands, the sink, with respect to OpenCascade Booleans?
I'm not trying to be confrontational, just trying to understand the tool.
User avatar
NormandC
Posts: 18534
Joined: Sat Feb 06, 2010 9:52 pm
Location: Québec, Canada

Re: BOP checks

Postby NormandC » Fri Jan 19, 2018 3:17 am

Look, you wrote

sgrogan wrote:
Fri Jan 19, 2018 12:16 am
Would you guys mind to check geometry w/BOP checks, both with the imported geometry and the final shape?
It is meaningless to check imported geometry with BOPCheck, because there are no Boolean operations in imported geometry. Imported geometry has no build history, it's just a set of faces stitched together to form a shape.
User avatar
sgrogan
Posts: 5425
Joined: Wed Oct 22, 2014 5:02 pm

Re: BOP checks

Postby sgrogan » Fri Jan 19, 2018 3:29 am

NormandC wrote:
Fri Jan 19, 2018 3:17 am
It is meaningless to check imported geometry with BOPCheck, because there are no Boolean operations in imported geometry. Imported geometry has no build history, it's just a set of faces stitched together to form a shape.
Perhaps, this is my mus-understanding. I think BOP checks, checks if an operand is suitable for a future boolean operation. Doing a BOP check on the result isn't validation of the previous operation, but rather if the result is suitable for a future boolean.
User avatar
NormandC
Posts: 18534
Joined: Sat Feb 06, 2010 9:52 pm
Location: Québec, Canada

Re: BOP checks

Postby NormandC » 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.
User avatar
Quaoar
Posts: 62
Joined: Thu Jul 27, 2017 11:56 am
Location: Nizhny Novgorod
Contact:

Re: BOP checks

Postby Quaoar » Fri Jan 19, 2018 6:23 am

sgrogan wrote:
Fri Jan 19, 2018 3:12 am
I didn't want to steal the other thread.
I understand it's not a general tool, but isn't supposed to inspect the quality of one of the operands, the sink, with respect to OpenCascade Booleans?
I'm not trying to be confrontational, just trying to understand the tool.
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.
FOSS CAD model inspection utility and prototyping framework: http://analysissitus.org
User avatar
easyw-fc
Posts: 2672
Joined: Thu Jul 09, 2015 9:34 am

Re: BOP checks

Postby easyw-fc » Fri Jan 19, 2018 9:38 am

Quaoar wrote:
Fri Jan 19, 2018 6:23 am
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.
as @wmayer reported, BRepCheck_Analyzer is callable by obj.Shape.check(True)
https://forum.freecadweb.org/viewtopic. ... 20#p205257
https://forum.freecadweb.org/viewtopic.php?t=22378
Still this method can give false positives.
User avatar
tanderson69
Posts: 1500
Joined: Thu Feb 18, 2010 1:07 am

Re: BOP checks

Postby tanderson69 » Fri Jan 19, 2018 3:43 pm

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.
User avatar
Quaoar
Posts: 62
Joined: Thu Jul 27, 2017 11:56 am
Location: Nizhny Novgorod
Contact:

Re: BOP checks

Postby Quaoar » Fri Jan 19, 2018 5:48 pm

tanderson69 wrote:
Fri Jan 19, 2018 3:43 pm
...
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.
Agree. Robustness is the most important factor, and, unfortunately, there is still a lot to be done in OpenCascade. Especially when you chain modeling operators one after another (like any CAD system does). Degradation in one operator complicates execution of the next one, thus making the final geometry worse again and again. Any means helping to prevent such accumulation of defects make sense, so bopcheck is at least giving you some metrics as long as the modeling process unfolds. I hope that at some point in the future we will not need that check anymore.
FOSS CAD model inspection utility and prototyping framework: http://analysissitus.org
User avatar
bernd
Posts: 8442
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: BOP checks

Postby bernd » Tue Jan 23, 2018 4:52 am

tanderson69 wrote:
Fri Jan 19, 2018 3:43 pm
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.
+1 I could not say it any better !
User avatar
bernd
Posts: 8442
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: BOP checks

Postby bernd » Tue Jan 23, 2018 4:55 am

Quaoar wrote:
Fri Jan 19, 2018 5:48 pm
I hope that at some point in the future we will not need that check anymore.
I do not believe in this because we will ever be exchange geometry between CAD. Means even if OCCT would not need it for it's own geometry. The check would be needed for imported geometry from other CAD which will be further worked with in FreeCAD (OCCT).