Good luck! CAD modelling is difficult even as a user, creating software that does it well must be significantly more so. I can sympathize with the OP regarding OpenSCAD. Beyond some of its technical limitations, it's missing some absolutely critical base features. One of the most egregious ones, in my opinion, is the lack of a simple builtin measuring tool[1]. There are threads going back to 2013 asking for this feature, with no plans to implement that I can tell.
Ahh, it is b-rep and intended to be language-agnostic?
Very cool.
OpenSCAD is fun but I am kind of reluctant to get too far into it when there's really only at best a difficult journey to STEP support (via the OpenSCAD workbench in FreeCAD).
And as for other CSG languages, Nick Lockwood's ShapeScript is fun:
(e.g. while I have exactly the kind of deep jQuery past that the CadQuery devs are trying to evoke, I'm not super-sold on that syntax; I happily gave up jQuery once there were better things!)
But unless something has changed since I read about it, it is limited to STL export.
While there are more and more ways to get STLs printed in novel materials, for some of the things I would like to make, a more traditional CNC route seems likely, and I'd rather start as I mean to go on.
This looks super exciting, particularly the idea of building a new Open-source B-Rep CAD Kernel. In fact that's (for me) by far the most exciting part! Open cascade is dated, somewhat difficult to work with and nowhere near as capable as commercial Kernels such as Parasolid.
Its going to be a mammoth undertaking to build a new kernel, the existing ones have taken tens of thousands of man years to get to where they are now. I do believe it's possible to start afresh though, by carefully selecting features to support and getting an MVP running it would then be possible to build something very impressive. Starting with a code first cad tool is a good idea, it purposely keeps things simple, and expectations lower.
I do believe there is a commercial market for this to - a cheaper and easer to use kernal to build cad products on would be very welcome, I could see the potatial for commercial investment in a open source kernal. I have a Mechanical/Industrial Design background as well as Software and often get tempted to try and build various CAD tool ideas I have, having a good modern foundation to build upon would be brilliant.
>> This looks super exciting, particularly the idea of building a new Open-source B-Rep CAD Kernel.
Yes, I think he's being rather naive about that. Starting with flat surfaces and straight lines is really ignoring the hard problems and will likely require a complete rewrite later. IMHO support for NURBS surfaces is a requirement for CAD and export/import of STEP files as well. Having said that, if he keeps going it will be a good thing. Some related efforts:
ruststep takes a similar approach to STEPcode but is written in Rust and produces Rust code. I wonder why nobody has a repo of the various STEP specs run through stepcode to produce usable C++ read/writer.
I think working on Open CASCADE may be worth peoples efforts, but I've opted to work on Solvespace instead. The core NURBS code is only about 8000 lines, while OCCT is absolutely huge.
I've been keeping an eye on this space as well, and while I agree with your first point, I have to say that I'm really more interested in the groundwork that these kind of efforts may lay for the future. For example, I know that there's currently a company called Foresight Mining Software[1] that is aiming to build a CAD product, in Rust, using the Bevy game engine (also written in Rust) on the backend. Even if it's not entirely FOSS, they are open-sourcing aspects[2] of their work that could help to accelerate the development of FOSS platform, or at the least, could eventually lead to true cross-platform general-purpose mechanical CAD support for platforms like Linux so that users aren't tied to Windows and the Dassault/Autodesk ecosystem.
Curves (currently only full circles) are supported, but the focus is on building a flat-faced/straight-edged MVP that support full CSG. It's possible that when this MVP is released, that curved edges/surfaces will be marked as experimental and not have full support for CSG, for example.
This is just a matter of priorities. Gotta start somewhere, then improve from there.
> Yes, I think he's being rather naive about that.
Oh yes, definitely :-)
Not in the sense that I think it's going to be easy, or anything like that. But I'm definitely (and consciously) focusing on the immediate next steps, while not really having a long-term plan. I do have enough of an idea of what I want to achieve, to know which direction to go in. And I'm doing that one step at a time.
This is definitely not the only way of tackling such a large problem. Someone else might approach this with a big vision and a solid plan, then use that to find the funding. I don't think either approach is inherently better, but the incremental approach is definitely a better fit for me.
> Starting with flat surfaces and straight lines is really ignoring the hard problems and will likely require a complete rewrite later. IMHO support for NURBS surfaces is a requirement for CAD and export/import of STEP files as well.
That's fair. And there are other valid criticisms as well, for example so far everything is single-threaded and CPU-based[1], which most likely won't do long term.
The thing is, I'm not capable of designing and then implementing a multi-threaded NURBS-based CAD kernel. I lack the expertise and experience. But what I can do, is design/implement this CAD kernel in an incremental way, step by step. One could argue, what's happening right now is the design process, and the implementation is just a useful side effect.
And we shouldn't forget, OpenSCAD exists and has its place. Something that's 80% as powerful, but has easy support for chamfers (and maybe some other goodies), would already be very useful to a lot of people. I'd rather focus on that and improve from there, than risk not getting anywhere, because I tried to tackle all the hard problems at once.
> Having said that, if he keeps going it will be a good thing.
Thanks! Maybe coupling the encouragement with criticism makes it more effective, not 100% sure :-)
---
[1] What I mean is, everything in the CAD kernel is CPU-based. The graphics are done using a GPU, of course.
My issues with OpenCascade and CGAL is that they are hard to compile. Any project using them is kinda a pain to build. This hurts developer adoption and puts up a barrier between the end users and the developers. In OSS, that barrier should be much more porous.
Rust projects (which Fornjot is) build nicely almost everywhere and can trivially target Wasm. Being in Rust will get a whole lot more folks involved in the project. One need not support every feature of OCC or CGAL.
Dated is the wrong term, it reinforces the temporal bigotry in tech.
I've never heard a person referred to as dated, so I'm not sure it directly implies any ageism towards people.
With tech itself, newer stuff usually performs better, is easier to use, and has better features.
Older stuff sometimes has one or two of them, but more newer has all of them more often than older, once the new thing reaches maturity(If that ever happens, since it often takes the aforementioned thousands of man years referenced in the thread)
Dated is a term that is often applied with a broad brush to software in the past. Giving undo credence to new over the old is what I am referring to with the phrase "temporal bigotry". New is not better, it is just new. The better part has to be proven. The ability to make poor choices, write bad code and ignore already working solutions is timeless.
Hey, author of Fornjot here. Thank you for the encouraging words!
> I do believe there is a commercial market for this to - a cheaper and easer to use kernal to build cad products on would be very welcome, I could see the potatial for commercial investment in a open source kernal. I have a Mechanical/Industrial Design background as well as Software and often get tempted to try and build various CAD tool ideas I have, having a good modern foundation to build upon would be brilliant.
I'd love to get there one day! I've already been in contact with potential commercial users (well, one), but very understandably, they'd like to see more progress before taking a bet on such an early-stage project.
For now, I'm relying on sponsorship from the community. It's not enough to cover my living costs yet, but the growth is there. I'm optimistic that it will reach a sustainable level before I run out of money.
I don't think that is a big issue at this time. The Rust code would be building a data model in memory, one could easily do an internal DSL or call it from an external language.
Exactly. All a model does, is build a C-ABI-compatible data structure. And even though Rust is currently the only language supported, Fornjot is architected to be language-agnostic.
I don't think Rust is the ideal language for this problem, but with Fornjot itself written in Rust, it was the easiest one to support. Gotta start somewhere.
They have to start with what's the easiest to implement, and if their kernel is in Rust, then the easiest frontend is in Rust. From their FAQ [1]:
> Fornjot is architected to be language-agnostic, and adding support for other languages should be relatively straight-forward, actually. Hopefully one day, there will be a selection of interoperable Fornjot frontends, so you can choose the best language for your model.
Some of that documentation exists in the issue tracker. But that vision is something I refine as I learn more about use cases and the problem space. So it's not like I can just write down the ideal state right now :-)
I have been working on a .net wrapper for opencascade (https://github.com/veggielane/EngrCAD) but opencascade interop from .net is a pain. I also fell in and out of love with SDF, as most CAM tools need BREP.
I agree with people in this thread, the world needs more CAD kernels. I also think that we need a language agnostic markup language to represent the BREP.
Yeah, agreed. Would be cool to have multiple CAD kernels using the same markup language, then you can easily version control and use it for interchange.
Out of curiosity, why did you fall out of love with SDF?
Also curious why BREP is represented through a language rather than e.g. a tree or graph (or maybe this is just a language shortcut, and the idea is that the language is used to specify BREP objects?)
Could you give a bit more detail on what you mean by that? The plan for Fornjot is to use WebAssembly as the intermediate representation for models: https://github.com/hannobraun/Fornjot/issues/71
My idea was more like building it as a tower of intermediate languages or representations.
Eg. You start with a core and pure language of primitives (for drawing and constraint solving), that should be easy to optimise and build sugared versions/higher level language that will translate/reduce into that core language.
It means at the end that we could have a higher level, declarative language/DSL that will generate the right underlying core representation (and you’ll compile that core language to webassembly or llvm ir for instance).
That’s how the latest advanced FP programming languages are built. Eg. you can check Idris2[1] or Formality[2] (small enough to understand the construction).
The analogy with llvm was to emphasise that you’d have a backend where your optimisation efforts should go, and your frontend(s) where your “ux” and ergonomics efforts should go.
Or put another way: build a “low level virtual machine” tailored for your specific topic, then the set of higher level languages that compile to its ir/bytecode.
I have had similar thoughts: Having a low-level representation that only makes sure that a geometric object you reference actually exists (and does other low-level validations), then have a wrapper around that, that provides higher-level operations and makes sure your model is also manifold.
This isn't thought out yet, just some stuff I've pondered. Thanks for providing more input to my thought process!
I think 3D modelling lends itself exceptionally well to the functional programming style. Rusts syntax is heavily influenced to solve a breadth of system level problems that don't exist in the "application" space this is solving.
I would argue such a system would be best implemented in a language that only has expressions. For example Elm has a wonderful geometry library [1].
The FP approach has some readability limitations, for example flexbox-like distribution of multiple elements over a distance requires some heavy recursion.
> edit: Models are defined as Rust code.
>
> Oh...
Not sure how to interpret that "Oh.." :-)
Rust is the only modeling language supported right now (give that the rest of the project was written in Rust, it was the easiest solution), but Fornjot is architected to be language-agnostic.
46 comments
[ 3.0 ms ] story [ 96.3 ms ] thread1: https://github.com/openscad/openscad/issues/1768
Very cool.
OpenSCAD is fun but I am kind of reluctant to get too far into it when there's really only at best a difficult journey to STEP support (via the OpenSCAD workbench in FreeCAD).
And as for other CSG languages, Nick Lockwood's ShapeScript is fun:
https://github.com/nicklockwood/ShapeScript
https://apps.apple.com/app/shapescript/id1441135869
But a path to producing STEP seems essential to me, to move beyond 3D printers.
CadQuery (especially v2) is fascinating and there's even a FreeCAD workbench for v2 now. Cascade Studio is very interesting indeed.
But I will be following this with interest. Not least because it might prod me into playing with Rust.
It's basically OpenSCAD but with Python and BRep (through OpenCascade).
It does have a bunch of useful characteristics.
(e.g. while I have exactly the kind of deep jQuery past that the CadQuery devs are trying to evoke, I'm not super-sold on that syntax; I happily gave up jQuery once there were better things!)
But unless something has changed since I read about it, it is limited to STL export.
While there are more and more ways to get STLs printed in novel materials, for some of the things I would like to make, a more traditional CNC route seems likely, and I'd rather start as I mean to go on.
Its going to be a mammoth undertaking to build a new kernel, the existing ones have taken tens of thousands of man years to get to where they are now. I do believe it's possible to start afresh though, by carefully selecting features to support and getting an MVP running it would then be possible to build something very impressive. Starting with a code first cad tool is a good idea, it purposely keeps things simple, and expectations lower.
I do believe there is a commercial market for this to - a cheaper and easer to use kernal to build cad products on would be very welcome, I could see the potatial for commercial investment in a open source kernal. I have a Mechanical/Industrial Design background as well as Software and often get tempted to try and build various CAD tool ideas I have, having a good modern foundation to build upon would be brilliant.
Yes, I think he's being rather naive about that. Starting with flat surfaces and straight lines is really ignoring the hard problems and will likely require a complete rewrite later. IMHO support for NURBS surfaces is a requirement for CAD and export/import of STEP files as well. Having said that, if he keeps going it will be a good thing. Some related efforts:
Another (stalled?) CAD kernel in Rust: https://github.com/ervanalb/arcade
Another one in Rust that can also read STEP: https://github.com/ricosjp/truck
That one reads STEP by using: https://github.com/ricosjp/ruststep
There is a geometric constraint solver written in Rust: https://github.com/Michael-F-Bryan/constraints to be used in another CAD: https://github.com/Michael-F-Bryan/arcs If I recall he moved all his work to gitlab. Here is arcs: https://gitlab.com/Michael-F-Bryan/arcs
All of this is very ambitious and I look forward to a day when a good CAD system written in Rust is readily available.
In the mean time I shall keep plugging away at the Solvespace C++ code: https://solvespace.com/index.pl
I think modifying Open CASCADE Technology would be a lot easier than starting again.
[1] https://github.com/stepcode/stepcode
I think working on Open CASCADE may be worth peoples efforts, but I've opted to work on Solvespace instead. The core NURBS code is only about 8000 lines, while OCCT is absolutely huge.
They get built as part of STEPcode.
[1] https://www.foresightmining.com/
[2] https://github.com/ForesightMiningSoftwareCorporation
is this flat surfaces only?
Looks to me like curves are passed to the lowest level: https://github.com/hannobraun/Fornjot/blob/main/src/kernel/g...
Curves (currently only full circles) are supported, but the focus is on building a flat-faced/straight-edged MVP that support full CSG. It's possible that when this MVP is released, that curved edges/surfaces will be marked as experimental and not have full support for CSG, for example.
This is just a matter of priorities. Gotta start somewhere, then improve from there.
> Yes, I think he's being rather naive about that.
Oh yes, definitely :-)
Not in the sense that I think it's going to be easy, or anything like that. But I'm definitely (and consciously) focusing on the immediate next steps, while not really having a long-term plan. I do have enough of an idea of what I want to achieve, to know which direction to go in. And I'm doing that one step at a time.
This is definitely not the only way of tackling such a large problem. Someone else might approach this with a big vision and a solid plan, then use that to find the funding. I don't think either approach is inherently better, but the incremental approach is definitely a better fit for me.
> Starting with flat surfaces and straight lines is really ignoring the hard problems and will likely require a complete rewrite later. IMHO support for NURBS surfaces is a requirement for CAD and export/import of STEP files as well.
That's fair. And there are other valid criticisms as well, for example so far everything is single-threaded and CPU-based[1], which most likely won't do long term.
The thing is, I'm not capable of designing and then implementing a multi-threaded NURBS-based CAD kernel. I lack the expertise and experience. But what I can do, is design/implement this CAD kernel in an incremental way, step by step. One could argue, what's happening right now is the design process, and the implementation is just a useful side effect.
And we shouldn't forget, OpenSCAD exists and has its place. Something that's 80% as powerful, but has easy support for chamfers (and maybe some other goodies), would already be very useful to a lot of people. I'd rather focus on that and improve from there, than risk not getting anywhere, because I tried to tackle all the hard problems at once.
> Having said that, if he keeps going it will be a good thing.
Thanks! Maybe coupling the encouragement with criticism makes it more effective, not 100% sure :-)
---
[1] What I mean is, everything in the CAD kernel is CPU-based. The graphics are done using a GPU, of course.
https://github.com/donalffons/opencascade.js
have it run in your browser
https://donalffons.github.io/opencascade.js-examples/demos/b...
Rust projects (which Fornjot is) build nicely almost everywhere and can trivially target Wasm. Being in Rust will get a whole lot more folks involved in the project. One need not support every feature of OCC or CGAL.
Dated is the wrong term, it reinforces the temporal bigotry in tech.
With tech itself, newer stuff usually performs better, is easier to use, and has better features.
Older stuff sometimes has one or two of them, but more newer has all of them more often than older, once the new thing reaches maturity(If that ever happens, since it often takes the aforementioned thousands of man years referenced in the thread)
Web3 is sadly changing this though.
> I do believe there is a commercial market for this to - a cheaper and easer to use kernal to build cad products on would be very welcome, I could see the potatial for commercial investment in a open source kernal. I have a Mechanical/Industrial Design background as well as Software and often get tempted to try and build various CAD tool ideas I have, having a good modern foundation to build upon would be brilliant.
I'd love to get there one day! I've already been in contact with potential commercial users (well, one), but very understandably, they'd like to see more progress before taking a bet on such an early-stage project.
For now, I'm relying on sponsorship from the community. It's not enough to cover my living costs yet, but the growth is there. I'm optimistic that it will reach a sustainable level before I run out of money.
Is this the syntax you want users to write? I...don't find it very readable.
I was assuming a dsl with kernel in rust.
I don't think Rust is the ideal language for this problem, but with Fornjot itself written in Rust, it was the easiest one to support. Gotta start somewhere.
> Fornjot is architected to be language-agnostic, and adding support for other languages should be relatively straight-forward, actually. Hopefully one day, there will be a selection of interoperable Fornjot frontends, so you can choose the best language for your model.
[1] https://www.fornjot.app/faq/
Making models more convenient to define is planned (https://github.com/hannobraun/Fornjot/issues/72), support for other modeling languages is on the wishlist (https://github.com/hannobraun/Fornjot/discussions/146).
I agree with people in this thread, the world needs more CAD kernels. I also think that we need a language agnostic markup language to represent the BREP.
I agree with that, but some serious decisions have to be made or it will end up a mess like STEP.
I don't know of anything that isn't useful in ISO 10303-21.
Also curious why BREP is represented through a language rather than e.g. a tree or graph (or maybe this is just a language shortcut, and the idea is that the language is used to specify BREP objects?)
I like BREP via language, it allows great flexibility and ability to query geometry at run time, e.g. Find all vertical edges to apply radius.
Could you give a bit more detail on what you mean by that? The plan for Fornjot is to use WebAssembly as the intermediate representation for models: https://github.com/hannobraun/Fornjot/issues/71
Not at this level.
My idea was more like building it as a tower of intermediate languages or representations. Eg. You start with a core and pure language of primitives (for drawing and constraint solving), that should be easy to optimise and build sugared versions/higher level language that will translate/reduce into that core language.
It means at the end that we could have a higher level, declarative language/DSL that will generate the right underlying core representation (and you’ll compile that core language to webassembly or llvm ir for instance).
That’s how the latest advanced FP programming languages are built. Eg. you can check Idris2[1] or Formality[2] (small enough to understand the construction).
The analogy with llvm was to emphasise that you’d have a backend where your optimisation efforts should go, and your frontend(s) where your “ux” and ergonomics efforts should go.
Or put another way: build a “low level virtual machine” tailored for your specific topic, then the set of higher level languages that compile to its ir/bytecode.
[1]: https://idris2.readthedocs.io/en/latest/implementation/overv... [2]: https://github.com/Kindelia/Kind https://github.com/VictorTaelin/Elementary-Affine-Type-Theor...
I have had similar thoughts: Having a low-level representation that only makes sure that a geometric object you reference actually exists (and does other low-level validations), then have a wrapper around that, that provides higher-level operations and makes sure your model is also manifold.
This isn't thought out yet, just some stuff I've pondered. Thanks for providing more input to my thought process!
I would argue such a system would be best implemented in a language that only has expressions. For example Elm has a wonderful geometry library [1].
[1] https://package.elm-lang.org/packages/ianmackenzie/elm-geome...
I (author of Fornjot) don't have any near-term plans to add support for other languages, but I hope that people will start experimenting (and someone already has: https://github.com/WeirdConstructor/Fornjot/tree/wlambda_int...).
edit: Models are defined as Rust code.
Oh...
Chamfered edges are definitely planned!
> edit: Models are defined as Rust code. > > Oh...
Not sure how to interpret that "Oh.." :-)
Rust is the only modeling language supported right now (give that the rest of the project was written in Rust, it was the easiest solution), but Fornjot is architected to be language-agnostic.