[HN Gopher] Fornjot: A next-generation Code-CAD application
___________________________________________________________________
Fornjot: A next-generation Code-CAD application
Author : sbt567
Score : 59 points
Date : 2022-03-08 06:32 UTC (1 days ago)
(HTM) web link (www.fornjot.app)
(TXT) w3m dump (www.fornjot.app)
| SOLAR_FIELDS wrote:
| 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
| unfocussed_mike wrote:
| 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://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.
| rq1 wrote:
| This is interesting. Though a new code-first approach should
| follow an LLVM-like architecture IMO.
| smallerfish wrote:
| ``` 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 wrote:
| Oh jesus, the model code is in rust?
|
| I was assuming a dsl with kernel in rust.
| adamsvystun wrote:
| 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/
| samwillis wrote:
| 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 wrote:
| >> 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
|
| 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
| ramboldio wrote:
| >> Starting with flat surfaces and straight lines is really
| ignoring the hard problems and...
|
| 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...
| qchris wrote:
| 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.
|
| [1] https://www.foresightmining.com/
|
| [2] https://github.com/ForesightMiningSoftwareCorporation
| rjsw wrote:
| There is also STEPcode [1], which can read and write STEP
| using C++, it has been kept up to date by the BRL-CAD people
| and is used by them.
|
| I think modifying Open CASCADE Technology would be a lot
| easier than starting again.
|
| [1] https://github.com/stepcode/stepcode
| phkahler wrote:
| 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.
| rjsw wrote:
| > I wonder why nobody has a repo of the various STEP
| specs run through stepcode to produce usable C++
| read/writer.
|
| They get built as part of STEPcode.
| jf___ wrote:
| Then again OCCT runs on JS & WASM in your browser
|
| https://github.com/donalffons/opencascade.js
|
| have it run in your browser
|
| https://donalffons.github.io/opencascade.js-examples/demos/b...
| zalo wrote:
| You can even get an OpenCascade IDE running in your browser!
| https://github.com/zalo/CascadeStudio
| axelerator wrote:
| 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-
| geome...
| engr wrote:
| 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.
| phkahler wrote:
| >> 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 wrote:
| In what way do you consider STEP to be a mess?
| engr wrote:
| 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 wrote:
| Couldn't one build a SDF-native CAM tool? That should be even a
| better fit than B-reps, no?
___________________________________________________________________
(page generated 2022-03-09 23:01 UTC)