Manifold Geometry // Многообразная Геометрия

Community digest

Подписаться на эту рубрику по RSS

Community digest series #01

Our forum slowly but surely becomes what it was supposed to be and what this blog failed to become: a knowledge database for CAD software engineers. Let's call these people "engineers" (although there is a different point of view on that matter) because it's not that much about programming and more about problem-solving. That's what new generations of project managers fail to understand about our business. While programming languages are essential, they are just programming languages, and one does not need to keep track of trendy frameworks and new language features to be successful in our niche. But I digress.

This message starts a new series of articles aimed at digesting the recent forum topics that deserve particular attention. On behalf of CAD devs, I'd like to thank all the folks who have actively contributed their time to growing the volume of content which would definitely help CAD software engineers in their work. These are my favorite (take it as a sort of "editorial note"):

Here are some other topics that might bring a value:

  1. OpenCascade 7.6 is released with (?) kinematics.
  2. Here is how to plug in the NetGen mesher to your OpenCascade-based app.
  3. Fast point-face classifier.
  4. A simple slicing algorithm.

Much more is yet to come. Now let's touch on each topic in some more detail. Btw, if you're interested in this CAD development business, it's probably the right time to join the forum unless you're already there.

Arrow glyphs in AIS

OpenCascade is known to contain its in-house visualization framework named AIS (Application Interactive Services). We are lucky to have Natalia who is excited enough with this framework to share her experience and pieces of advice that are impossible to get otherwise. If you wanna customize AIS for visualizing oriented glyphs, here's the topic to read.

Arrow glyphs in AIS.

To get as much as possible from the provided info, you might want to familiarize yourself with the Draw console of OpenCascade and look through the test scripts shipped with the library.

OpenCascade in Python

Prototyping with OpenCascade was supposed to be driven by the Tcl console named Draw Test Harness. At the same time, it has never actually worked that way for the community. Non-programmers prefer using Python, like it or not. Personally, I do not use Python a lot, but I can definitely appreciate the simplicity of this whole Python business and how much you can get from it without investing days and weeks of work. Read this topic if you want to get started with PythonOCC.

PythonOCC with the hello-worldy box.

The instruction assumes that you will use Conda package manager. If you are curious about what Conda is, the following topic at the FreeCAD forum can be an interesting supplementary reading: Let's talk about Conda.

Constrained filling

The constrained filling remains a largely unresolved problem in OpenCascade. Still, there are tools that might be of some help. One of such is the Plate algorithm: a pinnacle of scientific research conducted in Matra/Cisigraph back in the glory days of the library. Jojain translated the technical spec for the Plate algorithm which helps us better understand the principles behind this computation.

Open-sourced Plate is being demystified.

The Plate algorithm has found such applications as gap-filling or merging several surfaces into a single one. Somehow this tool became a universal solution for a variety of modeling problems and that is not exactly surprising as the surfacing API of OpenCascade is limited.

It seems to me that the Plate algorithm and all its incarnations are kinda done to death. Despite all the efforts by Jojain, it's still a challenge to fill all white spots in the theory behind this computation. Decades passed, and this whole surface modeling topic has to be revisited based on the recent state-of-the-art papers, also considering the existing commercial tools, such as the variational energy-minimizing xNURBS for example (although they kinda weirdly oversell themselves instead of keeping a truly scientific poker face).

Class A Bezier surfaces vs class B surfaces (from Rhino forum).

And I found some interesting thoughts by the Rhino user Tom in the discussion panel. Here's what he says:

"Basically, one aspect of class A is not using multispan. Although I would not strictly follow this rule, it is still important in most cases. One reason for this: the overall curvature flow drastically gets worse if you add knots. Why? Because even if you have G3 and higher in between each Bezier segment, you will have a hard time controlling it. You can apply an energy minimization, but that doesn’t necessarily solve your problem, because you cannot control and modify it. You have to live with the outcome."
A surface patch constructed with xNURBS for corner filling.

That reminds me of one French saying that I heard when I worked for OCC. I cannot reproduce it precisely, but the idea was that "B-splines are not necessary [sic]." If you design for quality, do it with Bezier. Now, this French school is all gone, but there's definitely something to learn from the available docs, and, again, Jojain's contribution is a good start here. We'll keep our investigation.

Geometric constraint solver

Geometric constraint solvers are primarily used to solve sketches, i.e., satisfy all the constraints imposed by the user. In OpenCascade, such solvers do not exist. For example, to develop the SHAPER module of Salome, OCC borrowed the PlaneGCS solver from FreeCAD. Adam shared the Python code that is used for sketch solving in CadQuery. He used NLopt to solve the optimization problem.