Homeomorphisms in OpenCascade
Before we move on to the subject of today's article, I must make a confession. I tried several times to cover exactly that topic and maybe the only outcome of these (largely failed) attempts was this brief and puzzling piece of text (in Russian): «К эйлеровым операторам: стягивание ребра». To those who have never delved deeper into OpenCascade waters, that technical memo would be hard to read. However, it did touch on one of the library's most important architectural concepts, the Modifier. This tool is realized in the BRepTools_Modifier class, which was introduced by Jacques Goussard in 1994. I once had the opportunity to discuss the subject with a man who worked on the roots of the library (he's now retired, but I heard he teaches math to children). When we got to the Modifier thing, he told me that the author, Jacques Goussard, was a "very mathematical guy," and he wouldn't be surprised if we called his Modifier tool an implementation of homeomorphism. Hence the title of this article.
Homeomorphism is exciting as long as you're not going to implement it.
To refresh your memory, homeomorphism is a type of shape modification that does not change the topology of the shape. When applied to B-rep, this principle means that the geometric data structures might get completely new curves and surfaces while the topology graph remains unchanged. We classified all geometric operators in a solid modeling library based on their level of intrusion into B-rep: read about it here. To recap on that matter real quick, the classification is as follows:
- Topology-only (super-fast, super-robust).
- Geometry-only (robustness is under control).
- Both topology and geometry (the worst case from computational point of view).
So today we're going to talk about the geometry-only operators because that Modifier thingy is all about such algorithms. Here are some examples of the modeling API functions that are geometry-only in OpenCascade:
- Conversion to splines.
- Conversion from splines (canonical conversion).
Remarkably, you can combine these approaches, running them one after another without necessarily baking everything into one ball of mud. Euler operators, for example, are pure topological algorithms, whereas edge rebuilding is a pure geometric computation. In our Blends Recognition and Suppression algorithm, we combined both (and I'm still thinking it wasn't such a bad idea after all). As a result, the algorithms of the third type can be designed as combinations of algorithms of the first and second types.
If these two splines are recognized as planar faces, they can be maximized into a single planar face.
Not surprisingly, the range of geometry-only operators is quite limited, because in a typical modeling scenario, new features are added and thus the topology of a part is constantly being altered. At the same time, in the feature recognition context, the topology-preserving operators begin to make sense. Let's return to canonical conversion for a moment. Converting spline-based shapes to analytical (or "canonical") counterparts adds no new boundary elements. Neither of these conversions will remove any edges or faces. So, if we want to implement such a tool while taking full advantage of what OpenCascade has to offer, we should look into the Modifier framework. It consists of two elements:
- The Modifier class (BRepTools_Modifier) is a data structure rebuilding algorithm that comes with OpenCascade and should not be customized: it should be just called.
- The Modification class (BRepTools_Modification) is a base interface that must be subclassed to provide your algorithm.
This seemingly exotic algorithm is a required component in all feature recognition (hence direct editing) workflows. To summarize the principle, the algorithm includes at least the following stages:
- Recognize free-form curves and surfaces as canonical geometries.
- Fit the recognized geometries with their canonical counterparts to measure the approximation error. If it's too high, the recognition is illegal.
- Rebuild the edges and faces by substituting their geometries with the recognized canonical curves and surfaces.
Some cylinders pretend to be splines.
So it looks wise to employ BRepTools_Modifier class when putting together a canonical conversion algorithm. As a bare minimum, we have to convert splines to at least two common types of canonical surfaces:
Converting to planes and cylinders should be good enough for a vast number of cases suffering from the non-canonical representation of boundary elements. Of course, there are many more cases to consider, and the trick here is to allow for future extensions. To convert spliny geometries to their canonical representations, use the following command in Analysis Situs:
> convert-to-canonical -tol 0.1
Conversion to B-splines
A reverse modification of converting a canonical shape to splines is also based on the Modifier framework. This procedure is readily available in OpenCascade's BRepTools_NurbsConvertModification class.
Convert the selected face to a spline.
You do not have to use the Modifier framework to build your own homeomorphisms on top of OpenCascade. But there is one clear advantage to this approach: doing so, you are not responsible for recomposing the topological structure of your shape. What you still have to do is override a bunch of functions for substituting your curves, surfaces, and vertices, and I'm not saying it's easy whatsoever. But at the very least, you can be certain that your shape is topologically consistent.
Want to discuss this? Jump in to our forum.