For example, the cgal library seems to provide many of the geometry-related aspects that are provided in OpenCascade. I cannot find many examples of Topology libraries, but I do see a few when I perform a google search.
I don’t claim to be an expert or even a novice with respect to computational geometry or the topological theory that is necessary in order to develop a BREP software. I am also very thankful to Dassault for originally releasing OpenCascade as open-source back in the late '90s. However, as old as the code base is and as many issues as we have, I find myself often wondering how difficult it would be to write a replacement. I have no misconceptions that this would be a large endeavour, and that if it is one that I wished to take upon myself I’d likely need to at the very least purchase a few textbooks to educate myself some more on how BREP works.
And yet, I still find myself mulling this over from time to time. So my question, then, is what is so unique about OpenCascade? Is it the relationship between the geometric kernel and the topological management that makes it a “CAD kernel”? How does the CGAL library compare to OpenCascade’s geometric facilities? Assuming CGAL is a worthy replacement for that portion of OpenCascade, would the last missing piece be to incorporate a topological component? Is the topological portion of the kernel “non-trivial”?
Please note that I do not mean to imply that any aspect of OpenCascade or a kernel in general may be considered “trivial”. However, if the topological component of the kernel needs to be, for whatever reason, deeply inter-twined with the geometric portion then I would consider this a “non-trivial” task to implement. However, my understanding of “good” software design is that it should minimize such tight coupling as much as possible. That being the case, I naively assume that if CGAL is a good geometric basis then writing a topological component in order to create a complete “CAD kernel” should be feasible.
I think “large endeavor” is an understatement. Do you want to spend the next fifteen years of your life developing a production ready CAD kernel? It sounds kinda like writing your own physically based render engine: educational and not that hard to implement the basics, but it takes a team and years to even get to the level of Blender Cycles not to mention the industry leaders.
It seems like what you learn from trying to implement your own CAD kernel would be better applied to fixing occt.
I can’t answer your actual questions because I know less about it then you , but I’m sure what CGAL provides is only a small part of what a CAD ready BREP library requires. CGAL doesn’t even have BREP algorithms, does it?
Well, the mysterious Russian Geometric Kernel was supposedly developed in just 3 years and should have some superior features over the other kernels, interesting however one of the companies behind it is using Parasolid in its commercially available CAD software
Not really. But then again, FreeCAD has been in development for 15 years itself. Just because it is a large project doesn’t necessarily mean it shouldn’t be undertaken. Also, there has been much development in the C++ language (and other languages) since OpenCascade was first released publically - certain aspects of OpenCascade that had to be implemented “from scratch” (i.e. “Handles”) are now provided as part of the STL (i.e. std::unique_ptr).
With the evolution of programming languages in the past 15 years, perhaps it would not take quite another 15 years in order to develop a suitable brep kernel.
Honestly, if I were you, I would ignore all realists and naysayers and go ahead with it just to find out for myself whether it would be feasible and to get a better idea of what is involved.
Thanks for the encouraging words. I’m not really too worried about “naysayers” as you call them. I am merely trying to collect data, and figure out what I don’t know
I thought I was the only one. I go through this about every six months. This subject gets brought up by everyone that tries to do anything beyond the trivial with opencascade. To answer your question: I don’t think there is anything special about occt other than it is pretty much the only thing that even attempts a modeling kernel in the open source world. I say get going! occt will be here after you realize that you are trying bail out the titantic with a teaspoon. At least that was my experience.
Cgal works with mehses only, so there are close to none similarities. The data structures, the algorithms, everything is completely different.
If you want something to base your effort on you shod use brlcad. They build a modeling kernel. Currently CSG only, but they are going to extend it with brep geometry and algorithms. To my knowledge the data structure is already implemented, and there have been first attempts at boolean operations. But they are not working yet. Don’t know what their planing is for the future.
A personal note from my assembly solver experiance: working with 3d geometry sounds rather easy in theory, the basic concepts are not so hard to grasp. However, there are so many, many, MANY special cases you need to handle that it is nearly impossible to create a stable and well working system without pure brute force coding power. There simply is no basic theory or algorithm that covers it all.
Thanks everyone for the input. This is the type of conversation I wanted to have, specifically some of the details ickby was able to provide about CGAL. I was considering attempting to write something based on CGAL but it seems that this will not be realistic.
Well, as I thought this would be a very large undertaking. It could potentially be quite fun though. I’m still currently working on the Topological Naming stuff, but if I can get that to a good point where it can be integrated into the FreeCAD code base, perhaps this would be a good project to pick up afterwards - it’s always fun to do challenging things and this would be quite challenging.
IMHO: I think there needs to be a champion to the cause. This evangelist would create a sign up sheet for developers and sponsors. He/she would then pester all possibly interested entities. Once the score gets upwards of about 10000 then maybe you can start designing and coding. Of course all these numbers are made up, but the idea still stands.
Individual:
name hours/week Ability(1-10) Score
bill 2 7 14
susy 4 9 36
…
It sounds kinda like writing your own physically based render engine: educational and not that hard to implement the basics, but it takes a team and years to even get to the level of Blender Cycles not to mention the industry leaders.
, but I’m sure what CGAL provides is only a small part of what a CAD ready BREP library requires. CGAL doesn’t even have BREP algorithms, does it?
I go through this about every six months. This subject gets brought up by everyone that tries to do anything beyond the trivial with opencascade. To answer your question: I don’t think there is anything special about occt other than it is pretty much the only thing that even attempts a modeling kernel in the open source world. I say get going! occt will be here after you realize that you are trying bail out the titantic with a teaspoon. At least that was my experience.