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
