2 ms·
It's not entirely clear (and I think you even said that) where this is going. Tangentially, there is IMHO a great need for new FLOSS geometric kernel for CAD ap
by phkahler 4y ago
It's not entirely clear (and I think you even said that) where this is going. Tangentially, there is IMHO a great need for new FLOSS geometric kernel for CAD applications. The only option right now are OCCT: https://www.opencascade.com/open-cascade-technology/ https://www.opencascade.com/open-cascade-technology/
which is really huge
Or the geometric code in Solvespace: https://solvespace.com/index.pl https://solvespace.com/index.pl
which is currently under 10,000 LoC: https://github.com/solvespace/solvespace/tree/master/src/srf https://github.com/solvespace/solvespace/tree/master/src/srf
This is far from perfect.
CAD systems use trimmed NURBS which have a lot of challenges. I wonder how choice of language would help to address some of the complexity. Addressing this is definitely a project unto itself, while having much narrower scope than a new Blender.
- kaveh808 4y agoI remember trimmed NURBS from back in the 80's, when the holy grail for 3D systems vendors was landing car companies as clients. It was not easy. Later, at Square on the "Final Fantasy" movie, we were having trouble modeling our character models using NURBS due to continuity issues when more than four patches met at a corner. I resolved the issue by implementing a subdivision surface plugin for Maya. Overnight the workflow switched to polygons. Would be great to have NURBS and other parametric representations as plugins in the system. One of the most exciting things about this project will be seeing what gets developed on top of the system.
- awolven 4y agoAs far as this thread relates to lisp, I have written OpenCascade bindings for CL: https://github.com/awolven/oc https://github.com/awolven/oc A truly new geometric kernel would be great, and it's been a dream of mine, but I have too many other things that need to be finished before I start writing one.
- kaveh808 4y agoWhat would a new geometric kernel consist of? I'm not a CAD expert.
- awolven 4y agoUsually when you talk about a geometric kernel in the past three decades, you're talking mainly about, but not exclusively about, a solid modeler. A solid modeler generally consists of a trimmed curve and surface library with lots of topological reasoning, to be able to represent closed regions of space and manipulate them by adding holes and rounding features and offsets. The idea is to be able to represent and operate on just about any 3d shape imaginable. Solid modelers of recent years have had support for nurbs surfaces and polygonal subdivision surfaces, but also include support for conic sections, beziers and other implicit or parametric curves or surfaces. Many of them, like OpenCascade are arranged in a logical object oriented fashion which abstracts the complexity. They have to be general, featureful and fast for anybody to want to use them. It's a whole heck or a lot of math and geometric reasoning (and debugging) which makes them valuable (and huge), and although you might want to talk about a "new" kernel you would never just want to chuck something like OpenCascade and start over. OpenCascade, ACIS, Parasolid, SMLib and others encapsulate a huge corpus of knowledge no matter what language they are written in. I have taken criticism from other Lisp hackers for writing Lisp bindings to OpenCascade instead of "starting over" in Lisp, but these people really have no idea what they are talking about.
- lispm 4y agoIt's not unusual to interface an existing geometric kernel from Lisp.
- kaveh808 4y agoWe shouldn't live in a bubble.
- kaveh808 4y agoInteresting. Sounds like a non-trivial undertaking. Both writing an interface or starting a new design. Either way, I would be happy if our system develops along to the point that serious engineering packages would want to use it.