Q&A from StackOverflow and more

I’ve been messing around with StackOverflow topics related to OpenCascade and found quite some interesting questions there. There are not so many, and definitely SO is not the right place to search for OCC community help. But people keep asking questions, and I could not resist the impulse of trying to answer them. Although this blog is definitely not the right place to answer OCC questions either!

So here is my "golden list" as of June 2021:

Question 1: about collision detection

Well, the answer was provided (click the link above) and it's definitely a good answer. Just to add another reference for those having the capacity of implementing things from scratch: [Christer Ericson. 2004. Real-Time Collision Detection. CRC Press, Inc., USA.]. That's a great reading containing tons of useful C/C++ code snippets with explanations and follow-up discussions. Personally, I've used a couple of functions from this book, and I'm looking forward to opportunities to dive deeper into that monograph and try more things out.

Question 2: CGAL versus OpenCascade

OpenCascade got quite a low grade in the first answer, while some reasoning about the quality looks a little bit speculating to me. To be honest, I never used CGAL (https://www.cgal.org/) in any industrial project, but I tend to think that CGAL is just a little bit out of scale. The reason for that is simple: CGAL does not lend itself as a full-featured CAD kernel, although I'm pretty sure it could be employed ad-hoc.

The following downsides of OpenCascade were brought to the table on StackOverflow:

1. All classes are declared in a global namespace (soooo bad).
2. There are parts of the library you have to pay for.
3. The library was never designed for public access, so it has some crappy stuff in its headers.
4. It has a very small community, so you're alone in front of the monster.
5. It comes up with one million ways of doing the same thing.

Well, let's go over these claims one by one.

1. Having all classes in a global namespace is not necessarily crap. It's rather a stylistic or design choice if you will. It's also largely determined by the long history of the library. Take VTK and C3D (the latter one is more relevant) as examples. None of these use namespaces and rather prefer specific naming conventions for file/class names to solve possible naming conflicts.


2. In the open-source OpenCascade you have everything you need to build up a classical parametric CAD software package. The commercial addons lurking behind the library are just domain-specific extensions and they do not come up with any critical functionality you will regret not having for free. For example, things like collision detection or canonical recognition have their own specific niches and you won't be blocked by not having them unless you are solving some less traditional modeling problem. These are just the more specialized SDKs.


3. Let's face it: none of the full-featured commercial-grade CAD kernels were ever designed targeting the public domain as a market. They all can be traced back to some originating commercial CAD system, which is Euclid Quantum for OpenCascade or Kompas for C3D. I wouldn't even turn this fact into a problem since a CAD kernel really has to be (you read this?) married to at least one CAD system to drive its development process. Nowadays, it's largely FreeCAD for the OpenCascade kernel. And let's not forget that OpenCascade accumulates decades of manpower and aggregates in itself some really amazing things contributed back in the nineties by French mathematicians and engineers. Not to speak about a great deal of work that has been done by the Russian team after publishing the kernel in the open-source. Think of this as a knowledge and skill depo that is simply impossible to end up with having no commercial interest.


4. OpenCascade has got quite a large community, but it is not as cultivated as we'd like it to be. It is diffused, but it's by no means rudimentary. A certain lack of development transparency and such barriers as CLA (contribution license agreement) have a somewhat negative impact on the people's willingness to contribute back, but it's not that bad. Personally, I find open-source community treatment in OCC to be quite Ok. But let's admit, it's hard to get help from others when you're dealing with OpenCascade, especially with its darker places. It is hard to know what the best/worst practices are. Therefore, I invite all interested folks to our brand new Analysis Situs Forums to discuss open-source CAD stuff and accumulate some hacks. Let's help each other.


5. Indeed, you can solve one problem in a number of ways, and that only complicates your path to getting things done. But, as practice shows, you are getting bothered with this sort of a problem mostly when it comes to some deep optimization and profiling. Building up an MVP with OpenCascade and the products around is a pretty simple task. That is why OpenCascade is so popular in research and start-up projects.

As a small wrap-up, let me share a bit of my modus operandi here. I use OpenCascade for more than 10 years already, and I'm not going to give up, because there's no alternative. But whenever I happen to hit the limitations of the library, I never tend to take other products like CGAL for the rescue, and prefer implementing the missing stuff from scratch. The truth is that other libs can do very little for you once you found yourself hitting the ultimate OpenCascade's wall. Unless you're trying to solve a problem that is out of the traditional CAD modeling scope, of course.

Question 3: direct editing?

There’s no easy way of doing this. OpenCascade was designed for history-based editing that assumes rebuilding your geometries from scratch (or starting from a certain cached version of it) whenever any design parameter changes its value. This discussion takes us to the holy grail of contemporary geometric modeling, which is direct editing. In OpenCascade, there is currently no such API.

I can share with you a little bit of experience here. To start off, any direct editing technique requires something called “local operation,” which is basically a way to modify your shape without rebuilding it from scratch. Think of dragging a vertex for example. One simple technique that can be employed for developing local operations is using the so-called Euler Operators. Did I say “simple”?

In our paper [Slyadnev, S. E., & Turlapov, V. E. (2020). Simplification of CAD Models by Automatic Recognition and Suppression of Blend Chains. Programming and Computer Software, 46(3), 233–243. https://doi.org/10.1134/S0361768820030081], we came up with a couple of Euler Operators for CAD model simplification. Just two of them: kell-edge-vertex (KEV) and kill-edge-face (KEF). And guess what? It was insanely hard to develop these two things on the top of a B-rep modeler like OpenCascade. I mean, it literally takes weeks to develop the operators that are trivially implemented in a couple of hours when dealing with meshes (think of edge/face collapse tools). If you want to know more about our simplification algorithm, check it out in Analysis Situs.

Let's finish for today. There are many more interesting questions to cover, but it starts to be too much for a single blog post. Stay tuned!

Want to discuss this? Jump in to our forum.