Fornjot – The world needs another CAD program
github.com
github.com
To name one: Booleans on NURBS are fare less robust in OpenCASCADE than their equivalent in commercial offerings.
Solidworks, Siemens NX, and OnShape all use the Parasolid kernel.
Inventor and Fusion360 use the ShapeManager kernel.
I use it as a 2D parametric sketch pad, for 2D designs for laser cutting, making 3D models for kicad, and a few basic 3D printed fixtures, but it is in no way a replacement for even Freecad.
The constraints are feature complete, but minimal. Some basic geometry is often a pain to get setup. Once you hit 3D you’ll realise that your basically limited to extruding and revoking sketches. Still a powerful tool but not suitable for serious mechanical design.
What world really needs is for FreeCad to be as usable is it’s paid equivalents. I don’t understand why free software always neglects the UI. How hard is it to even simply copy the time tested work flows in proprietary software. Once you learn Solidworks, Inventor, or Fusion 360, you can pickup any other parametric modeller.
Code as CAD as an idea I believe is flawed. It doesn’t solve any of the hard problems of mechanical design. Designing physical objects requires good visualisations and iterative feedback. I.e changing this dimension solves this interference in a complex assembly. Besides, most mechanical engineering are not proficient coders.
A straight copy would be sued out of existence.
I mean there is no reason why a visualization of the code could not be produced? It could visualize it in realtime after every save of the code.
Some have tried to generate things like CSS selectors for 3D geometry. It's clever but hard to use. In a GUI CAD system you just click on the edge. In a good GUI CAD system the selections are robust against slight changes in the feature tree.
SDFs let you say the reverse: by default fillet everything, and focus on finding ways to parameterise the fillet radius in ways that work for the part.
Any CAD package, code or visual, has only two ways to identify topological entities. Either you identify them from their underlying topology ("this edge is the 5th created by the intersection of objects A and B"), or you define some sort of query function over the final shape as it ends up in space, divorced from how it was created ("give me the edge that includes an arc in the XY plane radius r about point B"). Freecad does the former, from what I can see Onshape does something like the latter, but in both cases it's possible to generate a pathological feature tree which breaks under a change you want to make. How easy it is to make that breakage happen (or, conversely, how likely you are to accidentally trip over it in your day-to-day work) is controlled by how high the mountain of hacks is.
It's reasonable to say that no current CAD-as-code package solves the problem today but it's not true to say that it couldn't be done. The most obvious approach you could see is where the user clicks to select an element in a rendered preview and some selector string or other gets copied to to the clipboard that they then paste into the code to use directly, just like you can get a usable selector for a DOM element in the same format as you'd write by hand out of Chrome's Dev tools. That would work with either approach, and the fact that you're using a selector string in the same format as you'd write by hand means you can edit it as code when you need to.
The property of only working "as long as the feature tree remains stable" is a big part of the Topological Naming Problem, and it applies to both GUI and non-GUI environments.
In fact depending on the contextual information the GUI is able to obtain when the user clicks it is probably possible in many cases to ensure better stability than code only.
Again look at how OnShape records user selection via mouse click. It not only tries to record path information but also the 3D location of the click. Thus if the path lookup fails there is a fallback. The actual recorded data is quite unwieldy but as it is computer generated this is fine.
As you point out the "topological naming problem" is not guaranteed to be solvable under feature tree changes. However it can be often solved with heuristics that can be collected by an agent from analysing what the user clicked on and trying to figure out what makes that click unique. It's not 100% reliable but it is hard to do better or faster if you are hand coding a more than trivial part.
In fact depending on the contextual information the GUI is able to obtain when the user clicks it is probably possible in many cases to ensure better stability than code only.
Again look at how OnShape records user selection via mouse click. It not only tries to record path information but also the 3D location of the click. Thus if the path lookup fails there is a fallback. The actual recorded data is quite unwieldy but as it is computer generated this is fine.
As you point out the "topological naming problem" is not guaranteed to be solvable under feature tree changes. However it can be often solved with heuristics that can be collected by an agent from analysing what the user clicked on and trying to figure out what makes that click unique. It's not 100% reliable but it is hard to do better or faster if you are hand coding a more than trivial part.
Again I recommend you look an actual production system.
https://www.onshape.com/en/resource-center/tech-tips/tech-ti...
Where are these people? I see people saying it's possible, not saying it's just as easy. If you've got two different interaction modes, then some things are going to be easier in one than in the other, and vice versa. Otherwise there would be One True Interface, Autodesk would have patented the hell out of it, and nothing else would be worth building.
> ...heuristics...
Yes. I know. That's the mountain of hacks I was talking about upthread. And there's not a lot in there that you couldn't represent textually.
> Again I recommend you look an actual production system.
Already seen it, thanks.
Yes, I very much agree, but that is simply something that needs to be added to 'code as CAD' tools.
Software engineering has solved this a long time ago with self introspection.
OpenSCAD, to name a specific 'code as CAD' tool sorely lacks a way to "query" an existing assembly and use the result in subsequent modeling. If they added that, it'd be a quantum leap in modeling power for the platform. It's all the more frustrating that the underlying engine (CGAL) fully supports it with the ray-model intersection routine.
If you look under the hood as see how OnShape generates robust picking selectors it is not something you really want to try coding by hand. You can do it but it is non trivial.
Read
https://www.onshape.com/en/resource-center/tech-tips/tech-ti...
and
https://cad.onshape.com/FsDoc/library.html#module-query.fs
if you want to learn more how it is done. It is super awesome but not trivial to use.
Featurescript is designed to be used in within a GUI environment where you pick something specific and then a new custom feature is added to the feature tree. It is a hybrid code / no-code solution. The end user still performs the typical pick and configure workflow.
The line segment is not "defined" like a variable. There is no line in the code that gives you a declaration. It is a build artifact.
A rendering is not a build artifact except in the purest sense, it's just a different view into the source code. If you want to transition back to code you store the information required for it, it's not terribly difficult.
Another analogous feature is setting a breakpoint. They're not exactly equivalent, but depending on how the visualization is treated by the programming environment it covers what you're talking about.
In this case the key is the geometry and the value is the code that created it. But the real trick is to make sure the opposite is true, so you can go from code -> visualization and visualization -> code without a ton of difficulty.
Not sure what they have to do with signed distance fields. It's just an implementation detail for single dispatch. What's the analog?
In particular this is interesting, although as a mechanical engineer I don't see that as very practical: https://cadquery.readthedocs.io/en/latest/selectors.html
I mean I hate code cad but it is obviously useful to some people, specifically people with coding experience and no CAD experience that want to make a basic object to print on their 3D printer.
A program does not have to “solve the hard problems of mechanical” design to be useful to someone. TinkerCAD probably doesn’t solve those hard problems but is obviously useful to beginners.
I completely agree with you. There is plenty of room for a good code-cad, FreeCAD, Solvespace, and LibreCAD. I think we need to focus on improving each tool and better interoperability, which means DXF and/or DWG for 2D and STEP for 3D.
I have fallen into a particular trap before that FreeCAD also seems to walk into: encumbering the user interface with restrictions imposed by the requirement to be modular and extensible. As a result, the user often experiences much increased friction when some functionality needs to span the boundary of separate modules. I'd say that the spread of features across the many FreeCAD workbenches is a symptom of such software design driven UX.
Because most programmers aren’t very good at it and because it’s hard. For example, suppose you add a very simple parameter like setting the diameter of a circle. Internally that code is probably pretty simple. Once you expose it to users, you have an enormous amount of ground to cover. A few examples would include:
* How to handle a cancellation, such as the after pressing escape. Dismiss the dialogue? What if there are other settings in the same dialogue with newly altered values? Cancel the whole thing and lose other input or what?
* Undo, perhaps multilevel. If multilevel undo, do you set the number of levels yourself or do you allow that to be configured via a separate settings dialogue? Limit to memory or some fixed number of steps? Once saved, do you save those values in the user application data space, environment variables, a real database, the local directory, a hidden directory, or some combination of all these?
* Constraining input. You may not be dealing with keyboard input exclusively. Maybe you decide to let dragging the mouse set that value. Or maybe you want the up and down arrow keys to work, in which case you need to set an increment. Maybe that increment needs to be reflected in a Settings dialogue.
* What about units? Should they be integer, big integer, or float? Percentage or pixels or centimeters or inches?
* Accessibility. If voice input, do you come up with a of vocabulary of your commands for your app? If for limited range of motion, how do you design the dialogue to be visually attractive and not too cluttered but still useful for someone who can only move the pointing device a few millimeters at a time? What kind of color themes are accessible for the dialogue and the rest of the app? should these be supplied by the operating system or should you include color configurations as part of your app?
* How does the host OS handle flexible dialogue sizes and responsive screen size, if at all? Who does the UX for the mobile version? iOS only or also include android support?
This is a solved problem, though! You just do what SolidWorks or Fusion360 (IIRC the most popular CAD packages) do!
I find it more intuitive as a paradigm, but I think the real reason for lack of code interfaces in professional packages is probably because CAD models are built incrementally, and a lot of computation that the user doesn't notice gets baked in along the way. The workflows in CadQuery and OpenSCAD involve rerunning the whole script after every modification, effectively rebuilding everything from scratch each time, which quickly stops being fast as the model gets more complex.
Few key learnings I had about code vs visual (tldr it's complicated):
- It works great for flat laser cut assemblies, but once you start doing t-nut and finger joints you really need to see your pieces rotated and aligned in 3D. and that's a lot of extra code
- Writing a geometry library from scratch is really hard. I tried multiple newer JS libraries (that aren't ports of OpenCASCADE / CGAL) and all of them had numerous bugs in boolean operations, offsets, etc. There's just too many corner cases, compounding errors, APIs that haven't been thought thru and became a tech debt, etc.
- Maybe I'm looking in the wrong places or building a wrong thing, but there aren't that many users interested in "writing code for a 3d printer". Very few people dropping complex code cad projects on github. It feels like everyone who does is also building their own CAD platform ;)
[1] https://scriptcad.com , https://scriptcad.com/paulftw/OpenSCAD.Tutorial
My observation is that the problem isn't that the UI is neglected, it's that almost any suggestion to improve it gets bogged down in community objections. There's always someone on the forums who'll defend some aspect of the status quo (usually a vocal minority), either on the basis that "the problem is intrinsically complicated so a complicated UI is inevitable, so stop complaining" (which is, for the record, utter nonsense), or "we can't know if the change breaks someone's workflow", or "we need to expose the implementation details so you know what's going on" (again, nonsense).
What you end up with is evangelists on Twitter calling out for more contributions, and the community shouting down contributions which would actually help. The whole thing's fundamentally broken not because the code can't be written, or because the ideas aren't out there, but because it's incredibly hard to make progress unless you're already a core developer (which, yes, there are too few of).
Strongly disagree, the typical problems one has with designing objects and mechanisms in CAD tools are extremely similar to the problems software engineers have.
Parametric design, for example, is nothing but a program whose inputs change and whose outputs are 3D model.
Versioning is another obvious example.
Parts reuse yet another.
Test driven design.
Automated testing.
The list is very long.
> Designing physical objects requires good visualisations and iterative feedback
True, but I fail to see how that is incompatible with code as CAD.
> Besides, most mechanical engineering are not proficient coders.
In the 80's most traditional film animators had never touched a computer. These folks are now either out of a job or have switched to using computers.
The fact that mechanical engineers aren't proficient coders is a symptom of the fact that proper 'code as CAD' tools don't exist yet, not a law of physics.
When such tools start to reach maturity, you will see - just like it happened in film animation - a whole new generation of mechanical engineer pick up the new tools and beat the pants of the old way of doing things.
It is a very good tool, that does a lot of things better than visual CADs. But it's not good enough to do everything better than a visual CAD. At least not yet.
I don't, however, have experience with the commercial products since I'm not a professional engineer.
Are there other shortcomings you have in mind?
Because UX is multidisciplinary, which is hard when collaborators are loosely coordinated and even harder when the entire team is developers - or developer, singular.
Also, it requires knowing the users and walking in their shoes. That marketing attitude is absent when the project is about scratching one's own itch. Even when attempting to reach audiences beyond oneself, the change of perspective is hard while immersed in the project's internals.
Non-developers thinking they'll help will have a hard time establishing sufficient credibility for any sort of fruitful cooperation to occur. And that of, course, is before everyone starts getting territorial about it...
Can you recommend an (open/freemium) tool for (3D) modelling and animating a warehouse or a port?
I started with some excel analysis, and now a detailed agent-based modelling with a Java tool. Any tools to visualize (and animate) the physical layout??
Looks feasible. But i am not an electrical or production engineer.
I had a prof for a course on probabilistic methods in operations research whose work flow was to use Python for the modeling and simulation work, and then they would use AnyLogic to simplify the analysis and present a 3D overview of the process.
But AFAIK, it is not a full CAD program. But looking again at this demo [1], I realize you can go a long long way with it.
Solvespace maintainer here. I appreciate your assessment of Solvespace and feel it's accurate. My intent is to bring more capability to it while maintaining the feel of it which seems hard to quantify. I understand why people use FreeCAD - it's much more comprehensive. What's interesting is that you also use Solvespace because it's "better" in some way (and I agree). How would you describe that? What keeps you using it?
It is missing a few things, like selecting a face won't let me draw on that face, which it probably should allow since it technically knows all the information about that plane (face origin and normal). And Fusion360's inset tool is invaluable for making stepped features from existing complex geometry without having to redraw and constrain a whole new set of stuff. And also negative extrusion distances, which are basically a difference boolean operation, should probably be allowed for usability. But overall I'm very happy with Solvespace.
That's issue #423. https://github.com/solvespace/solvespace/issues/423
There isn't always enough information to create a new sketch plane, but often there is. It would probably be confusing to allow it on the sides of an extrusion but not the top and bottom. The changes needed to carry the extra information would break file compatibility, but I'd like to do a number of such changes all at once some day not soon.
>>FreeCAD spits out cryptic errors in a big log at the bottom that's pretty useless, but Solvespace tells you exactly what's wrong (generally)
I hadn't thought about error messages as a selling point, but I'll try to continue the trend of being informative.
This doesn't stem from the UI, but from the handling of core CAD data structures. For instance see the topological naming problem and the constraints it imposes on designers[0].
Realthunder3 has a branch that helps move a lot of this forward.
I will sign this with my blood. Why on Earth every free solution is trying to reinvent the wheel when it comes to proven and ergonomic UI is beyond my comprehension.
But I like that I can run it in Linux because it is browser based, tho I would prefer a local native app. Onshape is hard to use on a slow connection.
But I use it to design all kinds of complex robots and it is great.
The only open source program I've tried that comes anywhere close is Solvespace, but it's still not in the same league. FreeCAD is rubbish.
Fusion 360 was a reasonable free, legal but proprietary option until recently, but they changed the terms of the deal.
Now I just pirate Solidworks.
What I want is a project that is open source like Blender is open source. One that intends to be open source forever and also knows how to raise funds to manage a real engineering team.
2d construction drawings are usually enough to reason about your mechanical problems and I wish there was an open source software that would augment the worklflow based on a pencil-and-paper metaphor.
That is coming from a civil engineering background though, so there are less complex shapes I guess.
You can get somewhere with Incscape, but there is just so much missing, from file format handling to workflow. Being able to type in line lengths while drawing would already be much of an improvement.
I thought about learning enough c++ to implement some of the features, but as far as I could tell, submissions for more technical features coming from other people were (probably rightfully) dismissed as not fitting for the original intent of Incscape.
If I remember correctly, apart from clunky workflow it had too much visual clutter for me, especially when it comes to large drawings. Those visible constraints and anchor points let me loose the overview. I really only need black lines on white background; various thicknesses and hatchings. Using FreeCAD I'm always under the impression, that it's primarily made for smaller but more complex parts and not, say, a larger wood structure with wall details, where you need to take care of both the micro and macro view. I don't need constraints, as the placed lines are already the source of truth; measurements are mainly important while creating the object and for communicating to others while laying out plans, but rarely in between.
Maybe that's just an interface configuration issue though? And I guess the workflow is just something to get used to.
In the end my primary reason for looking for a program that is more drawing-like is to be able to teach people how to draw simple things on paper and then go "here's this program where you can do what you can do on paper, but you can edit it afterwards, align stuff easily and build complexity".
Maybe. I know there are two types of measurements in FreeCAD Sketches - ones that are actually constraining the design, and ones that you request to be displayed for other purposes. Maybe you could arrange to hide the constraining ones. If that's not already possible, it should be a trivial feature to add.
___
When I had a look at it, I was under the impression, that you can't get immediate enough to the core functions, for an extension to make sense. You are just drawing too many lines to make going through a pop-up every time feasible. You want to specify exact lengths while drawing, not afterwards.
In Vectoworks e.g. line drawing works like this: click on the starting point/node, choose the angle by moving your mouse, enter length (length field is always pre-selected), press enter. Optionally press tab to enter a more precise angle if it's not dividable by 15, but you probably have an alignment point selected already, so you don't need to put the angle or even the length. You do this 100 times in a row. And if you edit a shape, the measurement input is always immediately accessible aswell.
Adding a text and visual measurements is something you do when the drawing is complete and you manually lay them out, because you want to choose which measurements to include and you lay them out in a nice line so other people can easily comprehend what you want to communicate with you drawing. Sometimes you have the same drawing with different measurements, because you are communicating a different aspect of the drawing.
Last year I was looking for something with the same use case in mind. Quick 2D drawings, with modular blocks, and preferably open source. The closest thing I found is qcad [1].
It has a lot to offer, but not everything is intuitive. So for me it was necessary to do a few of the tutorials.
There is also LibreCad [2]. A fork of qcad, which looks more modern (I did not try this one).
Still I did not yet find something that "augment the workflow" of the pencil and paper metaphor for mechanical applications. This would be really cool. Maybe even something compatible with the newest eInk devices.
I'm a bit surprised there's no mention of it anywhere in the repository or on the website.
Yeah, that is a very weird choice indeed. Brings a ton of constraints to the user (borrow checker for 3d? why?) that have nothing to do with 3D modeling.
I would have understood something like Python or Lua a lot better.
I loosely followed a project of that kind a while ago, I don't quite remember if it was Gluon [0] or Dyon [1]. Not sure if these are still active, or if another competitor showed up in meantime.
___
> The modeling language for Fornjot is Rust. To me, this seems like an akward language to write models in.
I fully agree! Given that Fornjot is written in Rust, starting with Rust as the modeling language was just the most straight-forward option.
But Fornjot is architected to be language-agnostic. Right now, it uses a plugin system based on dynamic linking, and you could plug anything in there that can generate C-ABI-compatible structs (the plan is to replace that with a system based on WASM).
In addition, I've started splitting Fornjot into self-contained libraries[1]. Once that effort is complete, there will be lots of ways to make Fornjot available to other languages.
That said, I think there's merit in having options when using Code-CAD, and Rust is certainly different enough from the typical alternatives to be valuable. I don't think it will ever be the best option for regular CAD modeling, but it might have a niche in infrastructure code that CAD models (written in other languages) use.
> The most popular Code-CAD application, as far as I can tell, is OpenSCAD. While programming your CAD models, like you would program software, provides a lot of flexibility, the feature set of OpenSCAD is otherwise very limited. This makes many CAD modeling tasks tedious.
> I want to use something more powerful, and that rules out OpenSCAD and a whole bunch of other less-known alternatives.
[1]: https://www.fornjot.app/blog/the-world-needs-another-cad-pro...
I do wonder what kind of limitations the author ran into with OpenSCAD, and why they decided building a replacement code-CAD program was the best way to go.
More power to them, I guess - it'll be cool to see what comes out of this.
It's extremely painful to add fillets to anything by manually designing the geometry. There are a few libraries that try to provide the feature but they are forced to use a pretty inefficient minkowski math that brings your machine to it's knees, and they don't even work that well (can't actually handle every situation). And fillets are not just a nicity you can live without. They are critical all over the place.
The openscad feature set is pretty basic, but there are at least one or two projects that essentially transpile from python to scad. IE, you desribe a model in python with functions that do more powerful things than native scad provides, and it outputs scad code to make that model.
I haven't used those so I can't say more than that about them.
I still use openscad directly for a lot of things and live with it's limitations because to me it's just that huge to be able to check in the model in git and actually diff it and read the file and the diffs directly, and for a whole model to be described in a couple k of human readable text instead of 10 megs of binary or xml.
E.g. how does one place a sphere on top of a box? First you instantiate a box, then you calculate the center coordinate of the sphere and instantiates that one. If you have many objects touching each other, you're going to have a lot of maths there with a lot of variables or functions to reduce repetition.
A better way in my mind would being able to express things like "sphere of radius R has its bottom at center of box.top". Not even a constraint solver is required for this, though that could be nice as well, but would probably introduce its own set of problems :).
This kind of thing could be particularly nice with the interactive OpenSCAD editor that would enable quickly visually determining the locations of the anchors.
So yes it is a constraint solver, but a very simple one, as you can constrain only one parameter, but all others would need to be provided; I meant R to be such a provided value (can of course be a parameter to the function creating the object). Perhaps you could also implement is in a way that R can be provided but expect the code to provide all others.
A more general solver would be nice, but they don't seem trouble-free either. But sure, the syntax could be geared towards future development of such a solver.
Maybe there could be a particular syntax for invoking such a solver that would fit well with the existing system, e.g. an "object" that only has hook points that could be constrained in various manners, and then actual objects would use them as input coordinates.
> I do wonder what kind of limitations the author ran into with OpenSCAD
Lack of bevels/chamfers, no way to refer to existing geometry (to sketch something on a face and extrude that, for example), no constraint-based modeling, weird and limited language. Those are a few off the top of my head.
I don't want to speak badly about OpenSCAD. It's obviously very useful to a lot of people, and I myself keep coming back to it for my own projects (Fornjot isn't ready to replace it). But there are many good reasons to want something else.
> and why they decided building a replacement code-CAD program was the best way to go.
What would the alternative be, in your mind? Trying to join the OpenSCAD project, saying "I want to change everything", would just be rude.
I don't want to fork a big C++ project either, as I don't know the language very well and have no interest in learning it. I'm also not convinced that starting with a fork of something would be better, in the long run. There's value in looking at the problem with fresh eyes.
How do you solve that in "code CAD"? I mean referring to a geometry that's a result of some previous operations, not one that you manually created.
I've written down some preliminary thoughts here: https://github.com/hannobraun/Fornjot/issues/101#issuecommen...
And let me emphasize, these are just preliminary thoughts. I can see cases where what I wrote there won't work, and I'm sure there are many more problematic cases I haven't thought of yet.
There's still a lot of work to do before any of that even becomes relevant for Fornjot. I'll keep thinking about it in the background, but I don't expect to come up with a meaningful solution before I had a chance to really dive into the topic.
CadQuery has its own approach, which I have yet to study in detail: https://cadquery.readthedocs.io/en/latest/selectors.html
In addition to the article that agucova posted, OpenSCAD is also specifically called out in the FAQ: https://www.fornjot.app/faq/
Second question. (Sorry, there isn't a way to link to specific questions in the FAQ yet. I've made a note to add that.)
Fornjot: A next-generation Code-CAD application - https://news.ycombinator.com/item?id=30597061 - March 2022 (46 comments)
Embedding a Lua engine or some language in that vein would help drive adoption a lot.
Fornjot is written in Rust, so starting with Rust as the modeling language was the most straight-forward option. I do agree that Rust is not ideal for this use case.
Fornjot is architected to be language-agnostic. Long-term, I hope there will be a selection of interoperable options for the modeling language.
And yes, I do agree the world needs a code first open source CAD program :-) I've used openjscad in the past. It's fairly basic but easy enough to do the modeling part.
Anyway I'm happy to see this kind of projects even if I don't use "CAD-code"-oriented modelers (isn't it kind of similar to OpenSCAD?).
In any case I will consider paying for any FOSS project if it proves to be a viable alternative to Autodesk bloatwares.
Support for architecture use cases is currently listed on Fornjot's feature wishlist: https://github.com/hannobraun/Fornjot/discussions/146
As is noted there, I lack any expertise in this field, and it's largely unclear what specifically would be required to support it. Feedback is very welcome!
> isn't it kind of similar to OpenSCAD?
Yes, OpenSCAD is one example (the most prominent, I think) of the Code-CAD approach.
The Fornjot FAQ addresses OpenSCAD: https://www.fornjot.app/faq/
Second question. (Sorry, there isn't a way to link to specific questions in the FAQ yet. I've made a note to add that.)
https://github.com/ricosjp/truck
And it has a long way to go. They are tackling some hard problems like dealing with STEP format already.
There is also a geometric constraint solver written in Rust. He's moved to (I think gitlab) but here's the old repo: https://github.com/phkahler/constraints
If you are writing free software you have two choices - OpenCascade and CGAL. I looked at the source to see which this uses and ... it's rust. It uses neither. Probably why it doesn't have many features.
I know half-edge and similar data structures for polygon modeling, but I seldom see any materials on b-rep.
Academic works: Mäntylä: "Solid modeling" Faigin: "Curves and Surfaces for Computer-Aided Geometric Design" Stroud: "Boundary representation modeling techniques"
Implementations: Parasolid, Acis, OpenCascade.
From implementation point of it's CSG (i.e. implementing the boolean operations) that will be among the biggest hurdles and where most of the black art is.
With code, you just deal with... code, aka math. Parametricity comes essentially built-in, the way variables and functions are built-in to a programming language. Plus all the standard things we take for granted in coding – straightforward component and logic reuse, versioning, etc.
This domain is very complex, and really good code-cad tools don't exist (CadQuery is the most decent IMO, but it's far from perfect), so it's nice to see more attempts at solving this problem.
That is a common misconception, but in reality that's not how it shakes out. Realworld CAD software uses a geometric constraint solver because real world design problems have geometric constraints.
If you want to draw a rectangle with width X and height Y, sure you can handle that with variables.
What do you do if you want a triangle where one side is tangential with an arc, the other two sides have an angle Z between them and the intersection between that two sides is straight down from the center of the arc (that is they have the same x coordinate)? Is this description well-defined or do we need to give one more measure/constraint before it becomes so? Or maybe even over-defined and we can't possibly satisfy all these constraints?
This is the kind of question a geometric solver can answer, realtime as you are editing the sketch. You can try to cook up an ad-hoc solver every time you need one (with variables and functions) but then you are not in the business of designing stuff, but in the business of ad-hoc CAD development.
No worries if you haven't thought that far forward, that's also fine. :)
I know I want it, and that's about the extent of the design work. There's loads of more basic capabilities to add, before it makes sense to tackle constraints.
On top of all the other answers: being able to download and customize an existing model to your needs is way easier if the model is described by code.
If you could put together something on a Valve Steam Deck and send it to 3D printing, that’ll be a great step towards Drafting Dan.
> I do question whether Rust is the write choice for defining models,
You're not the only one :-)
As I've written in reply to other comments (here and elsewhere), it was just the easiest option to start with, given that the rest of the project is also written in Rust. Fornjot is architected to be language-agnostic, so we're not bound to Rust on the modeling side.
> but it does seem like a cool project.
Thank you!
Out of half a dozen parametric CADs I've used, onshape is by far the most intuitive and pleasant one to use. Not to mention it runs in the browser and gets updates every other week with no effort on my part.
Shouldn't this be a separate project?
> Shouldn't this be a separate project?
Maybe. Not right now, I think. Not much of a point, as long as I'm the one doing most of the work.
The kernel is available now as a separate library though, that can be used independently. If it attracts its own set of users and contributors, it might make sense to have a separate website and repository.
[1] https://en.wikipedia.org/wiki/Robust_geometric_computation
For example, you're not allowed to define a point that happens to lie on a surface. You must instead explicitly define the point in terms of the surface. By extruding from a sketch that lies in the surface, or by saying "extrude until the shape hits the surface", or by specifying some kind of constraint.
I hope that it is practical to design CAD models in a way, such that these relationships are always explicit, and I hope that this will enable the CAD kernel to not have to rely on messy floating point stuff comparisons. But as I said, not no idea if it's going to work out like that.
Another direction you could take is to define just the API, and use the opencascade kernel (like FreeCAD) until the rest of your code is ready.
> Another direction you could take is to define just the API, and use the opencascade kernel (like FreeCAD) until the rest of your code is ready.
A CAD kernel is the central dependency for any CAD program, and I feel that it would be wrong to just use one and accept its limitations. I need to be able to take ownership, to work on it directly. OpenCASCADE is a huge pile of C++ code, which is the opposite of all that. (Not saying it's wrong to use in general, just that I'm the wrong guy to work on a huge pile of C++ code.)
I've considered using Truck[1], but decided not to do that for now. I really want to see what I can come up with. If that doesn't work out, at least I'll be in a much better decision to decide what other option would be best.