7 ms·

Fornjot: A next-generation Code-CAD application

86 points by sbt567 5y ago

SOLAR_FIELDS 5y ago
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. 1: https://github.com/openscad/openscad/issues/1768 https://github.com/openscad/openscad/issues/1768
unfocussed_mike 5y ago
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: https://github.com/nicklockwood/ShapeScript https://github.com/nicklockwood/ShapeScript https://apps.apple.com/app/shapescript/id1441135869 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.
- dTal 5y ago
  There's also the undeservedly-obscure ZenCad: https://mirmik.github.io/zencad/en/index.html https://mirmik.github.io/zencad/en/index.html It's basically OpenSCAD but with Python and BRep (through OpenCascade).
  - unfocussed_mike 5y ago
    I looked at this but I didn't install it. 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.
samwillis 5y ago
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.
- phkahler 5y ago
  >> 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: Another (stalled?) CAD kernel in Rust: https://github.com/ervanalb/arcade https://github.com/ervanalb/arcade Another one in Rust that can also read STEP: https://github.com/ricosjp/truck https://github.com/ricosjp/truck That one reads STEP by using: https://github.com/ricosjp/ruststep https://github.com/ricosjp/ruststep There is a geometric constraint solver written in Rust: https://github.com/Michael-F-Bryan/constraints https://github.com/Michael-F-Bryan/constraints to be used in another CAD: https://github.com/Michael-F-Bryan/arcs 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 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 https://solvespace.com/index.pl
smallerfish 5y ago
``` let outer = args .get("outer") .unwrap_or(&"1.0".to_owned()) .parse() .unwrap(); ``` Is this the syntax you want users to write? I...don't find it very readable.
- properparity 5y ago
  Oh jesus, the model code is in rust? I was assuming a dsl with kernel in rust.
  - sitkack 5y ago
    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.
    - hannobraun 5y ago
      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.
- adamsvystun 5y ago
  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. [1] https://www.fornjot.app/faq/ https://www.fornjot.app/faq/
- hannobraun 5y ago
  Well, no. But it's what we currently have. As adamsvystun notes, I have to start somewhere. Making models more convenient to define is planned (https://github.com/hannobraun/Fornjot/issues/72 https://github.com/hannobraun/Fornjot/issues/72), support for other modeling languages is on the wishlist (https://github.com/hannobraun/Fornjot/discussions/146 https://github.com/hannobraun/Fornjot/discussions/146).
engr 5y ago
I have been working on a .net wrapper for opencascade (https://github.com/veggielane/EngrCAD 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.
- phkahler 5y ago
  >> 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.
  - rjsw 5y ago
    In what way do you consider STEP to be a mess?
    - engr 5y ago
      ISO 10303-21 is annoying to read and write, with an awful lot of stuff not used by CAD tools
      - rjsw 5y ago
        Don't read or write it then, use software that will do it for you. I don't know of anything that isn't useful in ISO 10303-21.
  - engr 5y ago
    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.
- ramboldio 5y ago
  Couldn't one build a SDF-native CAM tool? That should be even a better fit than B-reps, no?
rq1 5y ago
This is interesting. Though a new code-first approach should follow an LLVM-like architecture IMO.
- hannobraun 5y ago
  Hey, author of Fornjot here. 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 https://github.com/hannobraun/Fornjot/issues/71
  - rq1 5y ago
    Hi there. 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/overview.html https://idris2.readthedocs.io/en/latest/implementation/overv... [2]: https://github.com/Kindelia/Kind https://github.com/Kindelia/Kind https://github.com/VictorTaelin/Elementary-Affine-Type-Theory-legacy https://github.com/VictorTaelin/Elementary-Affine-Type-Theor...
    - hannobraun 5y ago
      Interesting, thanks for elaborating! 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!
axelerator 5y ago
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]. [1] https://package.elm-lang.org/packages/ianmackenzie/elm-geometry/latest/ https://package.elm-lang.org/packages/ianmackenzie/elm-geome...
- eurasiantiger 5y ago
  The FP approach has some readability limitations, for example flexbox-like distribution of multiple elements over a distance requires some heavy recursion.
- hannobraun 5y ago
  Fornjot is architected to be language-agnostic. Rust is just the easiest language to support, given that the rest of the project is written in it too. 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_integration https://github.com/WeirdConstructor/Fornjot/tree/wlambda_int...).
lloydatkinson 5y ago
OpenSCAD cannot do chamfered edges. I hope this will. edit: Models are defined as Rust code. Oh...
- hannobraun 5y ago
  Hey, author of Fornjot here. 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.

86 points by sbt567 5y ago

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. 1: https://github.com/openscad/openscad/issues/1768 https://github.com/openscad/openscad/issues/1768

unfocussed_mike 5y ago

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: https://github.com/nicklockwood/ShapeScript https://github.com/nicklockwood/ShapeScript https://apps.apple.com/app/shapescript/id1441135869 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.

dTal 5y ago
There's also the undeservedly-obscure ZenCad: https://mirmik.github.io/zencad/en/index.html https://mirmik.github.io/zencad/en/index.html It's basically OpenSCAD but with Python and BRep (through OpenCascade).
- unfocussed_mike 5y ago
  I looked at this but I didn't install it. 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.

samwillis 5y ago

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.

phkahler 5y ago
>> 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: Another (stalled?) CAD kernel in Rust: https://github.com/ervanalb/arcade https://github.com/ervanalb/arcade Another one in Rust that can also read STEP: https://github.com/ricosjp/truck https://github.com/ricosjp/truck That one reads STEP by using: https://github.com/ricosjp/ruststep https://github.com/ricosjp/ruststep There is a geometric constraint solver written in Rust: https://github.com/Michael-F-Bryan/constraints https://github.com/Michael-F-Bryan/constraints to be used in another CAD: https://github.com/Michael-F-Bryan/arcs 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 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 https://solvespace.com/index.pl

smallerfish 5y ago

``` let outer = args .get("outer") .unwrap_or(&"1.0".to_owned()) .parse() .unwrap(); ``` Is this the syntax you want users to write? I...don't find it very readable.

properparity 5y ago
Oh jesus, the model code is in rust? I was assuming a dsl with kernel in rust.
- sitkack 5y ago
  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.
  - hannobraun 5y ago
    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.
adamsvystun 5y ago
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. [1] https://www.fornjot.app/faq/ https://www.fornjot.app/faq/
hannobraun 5y ago
Well, no. But it's what we currently have. As adamsvystun notes, I have to start somewhere. Making models more convenient to define is planned (https://github.com/hannobraun/Fornjot/issues/72 https://github.com/hannobraun/Fornjot/issues/72), support for other modeling languages is on the wishlist (https://github.com/hannobraun/Fornjot/discussions/146 https://github.com/hannobraun/Fornjot/discussions/146).

engr 5y ago

I have been working on a .net wrapper for opencascade (https://github.com/veggielane/EngrCAD 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.

phkahler 5y ago
>> 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.
- rjsw 5y ago
  In what way do you consider STEP to be a mess?
  - engr 5y ago
    ISO 10303-21 is annoying to read and write, with an awful lot of stuff not used by CAD tools
    - rjsw 5y ago
      Don't read or write it then, use software that will do it for you. I don't know of anything that isn't useful in ISO 10303-21.
- engr 5y ago
  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.
ramboldio 5y ago
Couldn't one build a SDF-native CAM tool? That should be even a better fit than B-reps, no?

rq1 5y ago

This is interesting. Though a new code-first approach should follow an LLVM-like architecture IMO.

hannobraun 5y ago
Hey, author of Fornjot here. 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 https://github.com/hannobraun/Fornjot/issues/71
- rq1 5y ago
  Hi there. 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/overview.html https://idris2.readthedocs.io/en/latest/implementation/overv... [2]: https://github.com/Kindelia/Kind https://github.com/Kindelia/Kind https://github.com/VictorTaelin/Elementary-Affine-Type-Theory-legacy https://github.com/VictorTaelin/Elementary-Affine-Type-Theor...
  - hannobraun 5y ago
    Interesting, thanks for elaborating! 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!

axelerator 5y ago

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]. [1] https://package.elm-lang.org/packages/ianmackenzie/elm-geometry/latest/ https://package.elm-lang.org/packages/ianmackenzie/elm-geome...

eurasiantiger 5y ago
The FP approach has some readability limitations, for example flexbox-like distribution of multiple elements over a distance requires some heavy recursion.
hannobraun 5y ago
Fornjot is architected to be language-agnostic. Rust is just the easiest language to support, given that the rest of the project is written in it too. 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_integration https://github.com/WeirdConstructor/Fornjot/tree/wlambda_int...).

lloydatkinson 5y ago

OpenSCAD cannot do chamfered edges. I hope this will. edit: Models are defined as Rust code. Oh...

hannobraun 5y ago
Hey, author of Fornjot here. 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.