Utility to inspect OpenCascade models

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

Re: Utility to inspect OpenCascade models

Postby Quaoar » Wed Aug 30, 2017 1:35 pm

It is :(

I just do not have enough time to port it to Linux. Fortunately, there is no conceptual problem to do that. The problem is always to allocate enough time. Once I will do this, I will post here.

BTW, thanks for the explanation on face removal. Right now I am working on a more specific case: suppression of fillets. Still, the idea is quite similar.
FOSS CAD model inspection utility and prototyping framework: http://analysissitus.org
triplus
Posts: 9078
Joined: Mon Dec 12, 2011 4:45 pm

Re: Utility to inspect OpenCascade models

Postby triplus » Fri Sep 01, 2017 11:34 am

I remember i wanted to test CADRays at some point in the past but Linux version was never provided. Therefore the story ended there. ;)

P.S. From FreeCAD point of view Linux/Windows/macOS support is basically a must.
User avatar
Quaoar
Posts: 73
Joined: Thu Jul 27, 2017 11:56 am
Location: Nizhny Novgorod
Contact:

Re: Utility to inspect OpenCascade models

Postby Quaoar » Fri Sep 01, 2017 12:02 pm

The analogy is clear, but not fully correct ;)
CADRays is an official and closed-source product of OPEN CASCADE. This stuff is a hobby (well, used for work) and open-sourced.
FOSS CAD model inspection utility and prototyping framework: http://analysissitus.org
triplus
Posts: 9078
Joined: Mon Dec 12, 2011 4:45 pm

Re: Utility to inspect OpenCascade models

Postby triplus » Fri Sep 01, 2017 12:14 pm

I see. You therefore took much more FreeCAD-ish approach. ;)

P.S. +1
User avatar
tanderson69
Posts: 1510
Joined: Thu Feb 18, 2010 1:07 am

Re: Utility to inspect OpenCascade models

Postby tanderson69 » Fri Sep 01, 2017 7:42 pm

Quaoar wrote:
Wed Aug 30, 2017 1:35 pm
The problem is always to allocate enough time.
I sympathize. Take your time. I started doing some simple things like case sensitivity in cmake for files. I stopped when I read on your wiki that it was based upon some 'in house' libs.





Quaoar wrote:
Wed Aug 30, 2017 1:35 pm
Right now I am working on a more specific case: suppression of fillets. Still, the idea is quite similar.
Thinking about this again after a few years, It seems to me that occt has some nice routines for intersection and trimming with the bopalgo lib. But there doesn't seem to be anything 'high level' for extension, Which is a big part of this task.
User avatar
Quaoar
Posts: 73
Joined: Thu Jul 27, 2017 11:56 am
Location: Nizhny Novgorod
Contact:

Re: Utility to inspect OpenCascade models

Postby Quaoar » Sun Sep 03, 2017 12:59 pm

tanderson69 wrote:
Fri Sep 01, 2017 7:42 pm
Take your time. I started doing some simple things like case sensitivity in cmake for files. I stopped when I read on your wiki that it was based upon some 'in house' libs.
Thanks for your interest in this work. The most principal "in-house" lib is an object-oriented interface for OCAF which is used for data model design. I will open another repo for this study once CMake is ready.

tanderson69 wrote:
Fri Sep 01, 2017 7:42 pm
Thinking about this again after a few years, It seems to me that occt has some nice routines for intersection and trimming with the bopalgo lib. But there doesn't seem to be anything 'high level' for extension, Which is a big part of this task.
For me, the following operations are missing:

- Euler Operators to ensure topological validity of B-Rep model. And practice shows that it is not that easy as it may seem to implement them.
- Face removal operator. Yours look very promising. Hopefully at some point I will ask how you deal with "this and this" case.
- Local operators which are more lightweight than Booleans and which allow for local topological modification.

From direct editing perspective, I believe, OpenCascade really offers a sufficient number of intersection tools. However, when it comes to topology, things become quite messy. It is always a challenge to develop a reliable modeling algorithm without falling down to crappy spaghetti code which no one can understand and maintain. This is generally why I started this VTK-based utility. It gives me a framework for experiments together with inspection tools. Far from perfect, but I put my hopes to make it way better in the future.
FOSS CAD model inspection utility and prototyping framework: http://analysissitus.org
User avatar
tanderson69
Posts: 1510
Joined: Thu Feb 18, 2010 1:07 am

Re: Utility to inspect OpenCascade models

Postby tanderson69 » Mon Sep 04, 2017 2:49 pm

Quaoar wrote:
Sun Sep 03, 2017 12:59 pm
- Euler Operators to ensure topological validity of B-Rep model. And practice shows that it is not that easy as it may seem to implement them.
I figured you guys were getting close with the introduction and improvements to the volume maker algorithm. https://dev.opencascade.org/index.php?q=node/1062 I was always impressed with smlibs 'merge' operator. Never used it, just the idea. http://www.smlib.com/smlib.html#merge



Quaoar wrote:
Sun Sep 03, 2017 12:59 pm
- Face removal operator. Yours look very promising. Hopefully at some point I will ask how you deal with "this and this" case.
If I can help I will, but I am thinking you will fly right by me. I didn't make my point about the extension sheets clear. Referencing the example I posted earlier that removes the blend, I was thinking about extending both open boundaries until an intersection, then using the volume maker algorithm to 'recreate' the solid. Of course that sounds simple and probably wouldn't be efficient, but might work.


Quaoar wrote:
Sun Sep 03, 2017 12:59 pm
It is always a challenge to develop a reliable modeling algorithm without falling down to crappy spaghetti code which no one can understand and maintain.
It is good to hear you say that. I always feel stupid after a few hours of occ programming.


Quaoar wrote:
Sun Sep 03, 2017 12:59 pm
This is generally why I started this VTK-based utility. It gives me a framework for experiments together with inspection tools. Far from perfect, but I put my hopes to make it way better in the future.
I think this utility is important and I wish you the best of luck. how does your utility interact with the algorithm you are developing. Do you develop inside a dll/so and load it into your utility to test? Do you have some IPC so your algorithm can stand alone?
User avatar
Quaoar
Posts: 73
Joined: Thu Jul 27, 2017 11:56 am
Location: Nizhny Novgorod
Contact:

Re: Utility to inspect OpenCascade models

Postby Quaoar » Mon Sep 04, 2017 4:45 pm

How does your utility interact with the algorithm you are developing. Do you develop inside a dll/so and load it into your utility to test? Do you have some IPC so your algorithm can stand alone?
This is done in quite a straightforward way. No smart idea is behind. To make inspection tool aware of a new algorithm, there are two ways:

  • Simply link the tool against the library containing your algorithm. This way you just create another specialized executable to test _this_ particular algorithm. As a strong point, you obtain a demo software right from your testing workbench.
  • Load the algorithm's library dynamically via Tcl plug-in. In this case you use the standard GUI but you may give it custom console commands.
This mechanism is in fact very similar to the good old Draw Test Harness (https://www.opencascade.com/doc/occt-7. ... rness.html). It can also be either extended in a more application-specific executable, or you may construct a plugin dll/so to load dynamically. I believe that Draw is a very good tool from methodological point of view. Unfortunately, it is very old-school on the other hand, and it is not easy to prototype things with it.

To maintain an algorithm, two mechanism are proposed: logger for sending text messages and reporting progress, and graphical plotter for visualization of working variables (points, curves, surfaces, topological elements, polygons, etc.). The algorithm is provided with abstract tools to send messages and draw intermediate results. The tool to plot we call an "imperative plotter" as it allows drawing primitives in "cout"-like manner (some details in Russian are available here: http://quaoar.su/blog/page/imperativnyj-vizualizator). The interfaces are abstract. The inspection tool provides VTK-based implementation of these interfaces which enables visual debugging in VTK+Qt environment. However, there can be other implementations.

The problem is that such an approach is intrusive since the algorithms have to use some externally defined tools for messaging and plotting. This can probably be improved, but I am not sure how at the moment.

I was always impressed with smlibs 'merge' operator. Never used it, just the idea.
Yes, SMLib is inspiring. I think that OpenCascade Booleans are following the right way. E.g. if you check a paper by D. Jackson from 1995 ("Boundary representation modelling with local tolerances") you may find that OCCT Booleans are quite similar to Parasolid Booleans in the principle.

Referencing the example I posted earlier that removes the blend, I was thinking about extending both open boundaries until an intersection, then using the volume maker algorithm to 'recreate' the solid. Of course that sounds simple and probably wouldn't be efficient, but might work.
It might. And the current trend is to base most of modeling operators on Booleans which is totally correct because you always need a kind of "boundary evaluation and merging" tool. The only point is that some operations are local in nature and can be theoretically implemented without employing global BOPs. This is what is called LOPs (Local OPerations). OCCT had some in the past, but they were not robust. Euler Operators are foundation for this kind of tools.

It is good to hear you say that. I always feel stupid after a few hours of occ programming.
Absolutely ;)
FOSS CAD model inspection utility and prototyping framework: http://analysissitus.org
User avatar
tanderson69
Posts: 1510
Joined: Thu Feb 18, 2010 1:07 am

Re: Utility to inspect OpenCascade models

Postby tanderson69 » Tue Mar 27, 2018 2:51 pm

Quaoar wrote:ping


This is great news!
https://dev.opencascade.org/index.php?q=node/1211
User avatar
Quaoar
Posts: 73
Joined: Thu Jul 27, 2017 11:56 am
Location: Nizhny Novgorod
Contact:

Re: Utility to inspect OpenCascade models

Postby Quaoar » Tue Mar 27, 2018 3:09 pm

tanderson69 wrote:
Tue Mar 27, 2018 2:51 pm
This is great news!
Yes, this is a masterpiece done by our modeling guru Eugeny. Integrating it into FC can be interesting. I am still about to check this defeaturing functionality myself, though the results I have already seen are impressing.
FOSS CAD model inspection utility and prototyping framework: http://analysissitus.org