“Code-cad” as they put it clearly appeals to a lot of people, and more CAD is good. But as a long time mechanical engineer and robotics engineer what I really want is a completely open source parametric cad program that is as good as Solidworks or OnShape. FreeCAD is an impressive project but clearly needs more resources to ever compete. Solvespace seems cool and I want to play with it more, but I can’t comment on how good it is as I have only tinkered. I do wish the Solvespace UI was more akin to tools I am familiar with (OnShape or Solidworks).
I love solvespace, the UI is quick, minimal and easy to come up to speed with.
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.
> 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.
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).
> I don’t understand why free software always neglects the UI.
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?
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.
As evidenced by this thread, Openscad is not good enough to be a proper 'code as CAD' tool. If it was, we wouldn't be having this conversation.
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.
The main gripes I have with it are that it doesn't use all available processors and it doesn't have easy-to-use generalized fillets. I feel like the algorithms must be inefficient even considering it runs on a single CPU.
I don't, however, have experience with the commercial products since I'm not a professional engineer.
Implementing a good complex UI takes a lot of effort. It requires a clear vision, quite thankless attention to details, tedious iteration and something that open source software projects struggle with: willingness to sacrifice cleanliness of the implementation to improve the UX.
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.
> 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.
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.
The problem CAD as code doesn't easily solve is how to refer to parts of the generated model for further processing. Consider adding in fillets to parts of your model. You have generated something complex through a series of sketches and extrusions in different orientations. Now you wish to round off some of the sharp edges in the resulting model but not all of them. Using CAD as code you have the problem of trying to select which edges you want.
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.
> The problem CAD as code doesn't easily solve is how to refer to parts of the generated model for further processing.
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.
Tell me. How has software engineering solved a long time ago how to select the single segment shown here? The one marked yellow is selected. https://i.imgur.com/rbGDsvF.png I just picked this with my mouse within OnShape and it took me one only second to robustly pick it.
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.
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 definition isn't explicit. That curve - and several other - is the result of a single CSG operation. It might be possible to describe it in terms of the things that generated it, but that's way harder to do than selecting it with a mouse.
And how would you implement "Goto definition?" For a line segment that you didn't directly create and is an incidental artifact of a sequence of CSG operations.
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.
With a table that stores the source locator of the operation that generated the visualization and a program to query this table.
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.
Not really, vtables are a way to implement dynamic dispatch. A "table" is just a key/value store (in a vtable, the key is a function/method identifier and the value is the function itself).
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.
Vtables are the digital analogue of signed distance fields. That is the trick. Rust gets this right. It is why most rust developers use text editors instead of UML diagrams. We can do the same with CAD. Instead of using a transformer network put the whole geometric inversion in level 1 cache and dispatch through the vtable. The borrow checker does the rest for you. No need to use the mouse anymore. The geometry inversions are now just a keyboard press away.
Rust doesn't use vtables by and large - like I said it's a technique for implementing dynamic dispatch (call a function with a different implementation based on the type of one argument, aka single dispatch). Notably, Rust does not rely on it for most cases (Rust uses type classes aka traits which are monomorphized - unless you explicitly use the `dyn` keyword to use a vtable implementation that incurs a slight performance penalty).
Not sure what they have to do with signed distance fields. It's just an implementation detail for single dispatch. What's the analog?
Signed distance fields are like vtables. You can invert the cross product and you can introspect information that is otherwise not observable. That is you call a method in user space and it is dispatched to the origin. It is a monad or more specifically an applicative over the geometric inversion. Instead of selecting the segment with the mouse you perform a bind over the generative original data. Thus the projection in the limit provides the functor towards the flat space in which exists the segment that requires selection. You are right. Vtables are not enough but with the borrow checking rust provides you no longer need to track the ownership of the space vectors of the transitive solution. It's pretty complex stuff as a library writer to formulate but once encoded it is not much harder to use than a CSS selector. If you spend a few minutes thinking about it anybody could code it up I'm sure.
How does a signed distance field robustly allow you to select one edge out of many considering that these edges are an artefact the previous CSG operations you may have performed? These edges may or may not exist, their adjacent faces may or may not exist. They may be an in a non obvious orientation or be near or far from other edges or faces. Any query language or filter would need to be able to robustly handle such a system. OnShape has this but it is not for end users. It is for library developers. End users still get to point and click because it's the most obvious and simple thing to do.
I mean that part of the problem isn't unique to CAD as code. You've just described the Topological Naming Problem, and handling it is a complete mess.
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.
Nothing does. That's what I'm getting at. SDFs give you a different way of thinking about the problem to avoid having to make the selection explicitly which, when you can get away with it, solves for an interesting subset of the problem space, but there is no general solution to the problem you're describing, visual CAD or CAD-as-code. What we do have are mountains of hacks that more or less work to hide that fact.
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.
This is exactly what OnShape does. When. You click they generate two things, an id for that which is selected based on a feature path as well as the region that was clicked along with the type of object. The first works as long as the feature tree remains stable. This is only possible with a GUI selection mechanism which you acknowledge. As OnShape provides a powerful scripting system called feature script the future you imagine is already here. I wrote my own feature components for surfboard design using it.
It's not only possible with a GUI selection mechanism, that's just one way to get at them. If you've got a human-readable selector, it should be human-writable as well, and there will be cases where you would want to do that.
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.
I think we both agree that stability is an issue. I'm only taking issue with the 'code only' crowd who are claiming that it's just as easy to SELECT an object via code as with a mouse. It is not.
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.
> I'm only taking issue with the 'code only' crowd who are claiming that it's just as easy to SELECT an object via code as with a mouse.
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.
I think we both agree that stability is an issue. I'm only taking issue with the 'code only' crowd who are claiming that it's just as easy to SELECT an object via code as with a mouse. It is not.
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.
> I don’t understand why free software always neglects the UI
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...
>> I love solvespace, the UI is quick, minimal and easy to come up to speed with.
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.
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?
Not the person you're replying to, but in my experience going from Fusion360 to a new program due to license changes, FreeCAD has a lot of "boilerplate work" you need to do in order to get to modelling, including understanding the toolbars you need, parts, etc. but in Solvespace it's pretty much just draw and constrain like in Fusion360. 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).
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.
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.
> 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.
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 mean I hate code cad but it is obviously useful to some people...
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.
A bigger reason that FreeCAD isn't as good as it's paid equivalents is the lack of reliable undo (as well as a few other problems caused by the same issue).
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 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.
I spent quite some time in FreeCAD, then switched to makerjs. For the last two covid years "code cad" designs for laser cutter have consumed most of my free time.
I am also building my own online editor with focus on UX and live reloading [1].
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 ;)
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??
AnyLogic has a personal learning edition you might be able to use depending on your use case.
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.
Woah thanks for the rec! I’ve been frustrated with the tools I’ve tried for making laser cutter designs and something free and parametric is just what I’m looking for!
I'm guessing you've been fortunate enough to have never used Catia. I used to think FreeCAD was super meh because I was extremely familiar with Solidworks (I've used Inventor, NX, and Creo as well professionally). I learned and use Catia recently and finally understand why FreeCAD is made the way it is.
I find Catia a lot better than FreeCAD. It's not my preferred interface but on the other hand it can handle anything, including projects so large and complex that Solidworks/Fusion/FreeCAD can't even be considered.
>"...what I really want is a completely open source parametric cad program that is as good as Solidworks or OnShape..."
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.
Competing with those proprietary mcad will take a much better CAD kernel. FreeCAD uses OpenCASCADE. It's going to take a lot of time and effort to create a new one. There are a few projects around. I hope that one of them will catch on and get enough developer attention.
As a long time CAD user I was surprised to learn that a CAD kernel exists as a concept and that the same kernel is licensed and used in competing CAD packages.
Solidworks, Siemens NX, and OnShape all use the Parasolid kernel.
Inventor and Fusion360 use the ShapeManager kernel.
I think that a non-open source, native desktop, sane license, competitor for Solidworks/Inventor/Fusion would do well too. Solidworks is on a path to subscription-only / in the browser where Fusion and Inventor already are. Jetbrains?
Would you want this because its open or because it is free? I've always found SW amazing and intuitive with great help and assist, and sure it's expensive for a hobbyist but for a company it's not a big deal.
https://qht.co/item?id=30695360 was posted a couple weeks ago. Curious if that's sort of along the lines of what you're looking for. It's not exactly free software, but maybe it's open enough?
No because it is a NURBS modeler and not parametric CAD, so it is not at all the right kind of CAD, but also because it is not really open source (uses an expensive closed kernel) and will be less open source soon.
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.
How is your experience with OnShape? I find the web-based approach really appealing but have been concerned it would be more limited than desktop counterparts like Creo or SOLIDWORKS, and potentially more painful to integrate with PLM systems.
Aside from the fact that is is proprietary and cloud based, I love OnShape. It does have some limitations, like operations that logically should make sense but will just fail, but this is what makes CAD very hard even for a large experienced team like OnShape.
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.
OnShape is definitely more limited, even compared to Fusion 360. However, I've moved to it as my main CAD tool, since it works on Linux and Fusion 360 licensing is so problematic. Fusion 360 also has a web interface, but it doesn't support Linux, and even on Windows doesn't work very well. The only thing I've needed to go back to Fusion 360 for is thread modeling.
What I really miss is a parametric vector drawing software (like earlier Vectorworks). I don't need 3d capabilities, as long as I don't 3d-print, and with a good 3 axis cross section drawing you are almost there anyways in most cases.
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.
Have you tried doing it as an extension [0]? Or, maybe even simpler, use an Inkscape scripting extension [1]. I haven't tried that myself yet, just following the repo loosely. But I feel something like "select two points, draw an orthogonally aligned double-arrow based on the two x/y pairs, measure its length and add some text" should be possible.
I thought about it, but should take another look at it, that scripting extension looks like a good way to get in touch with it.
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.
"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."
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 have tried it, but ages ago. Maybe I'll give it another try.
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 that's just an interface configuration issue though?
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.
OpenSCAD is mentioned in the first article in the website, “The world needs another CAD program” [1]:
> 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.
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.
Many. Just one example is fillets.
They don't exist.
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.
> 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.
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.
I think OpenSCAD desperately needs some kind of anchors.
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.
A thing that can understand "sphere of radius R has its bottom at center of box.top" is exactly a constraint solver, so I'm not sure what you mean by saying it's not necessary for that to work. You have constrained R, and the location of a particular point, and the free parameter - the center point of the sphere - must be calculated from those constraints. And if you don't want the sphere to be exactly in the center? Suddenly you have only constrained 1 out of the 3 axes of the centerpoint, and will need additional constraints to disambiguate the shape. Or what if you want to fix the centerpoint and have the radius vary?
Both objects would have certain fixed hook points, such as bottom/right/center/etc and then the equation is as equality of exactly two of those points (new points could be derived from the existing ones, to express "1 mm Z from top").
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.
The modeling language for Fornjot is Rust. To me, this seems like an akward language to write models in. Not saying that OpenSCAD:s modeling is amazing though.
> 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 modeling language for Fornjot is Rust. To me, this seems like an akward language
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.
This should be a good use-case for rust-based scripting languages, I think.
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.
Rust has macro which allows you to write domain specific language if you want. The examples right now, is written in rust as they are still developing it. You need to have a solid core before building a domain specific language on top it.
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.
This is a really exciting to me.
As a libre-enthusiast who happens to be working in architecture, it seems I have been cursed by fate. Architecture is probably one of the least penetrable field of FOSS. I work in both 2D (for "classical" architectural plans) and 3D (for renders) and even though I make my photorealistic renders in Blender, I still have to rely on extremely locked-down and frankly annoying proprietary software (namely from the Autodesk brand), and there's no sign of improvement anywhere.
Tangentially, I have reached the conclusion that spending less time in front of the computer is the surest way to feel better about and (actually) improve the quality of my work.
I've been testing a new workflow involving Wings3D (as a SketchUp-replacement) but it's a tough call.
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.
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 goal "a new b-rep CAD kernel, written in Rust;"[0] is extremely ambitious. This would be the single most valuable long term contribution coming from this project if it succeeds.
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
I'm not sure about a CAD program, but the world definitely needs another geometric modeling kernel.
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.
As an innocent bystander my perception is that B-Rep modelling is 75% academically well known and 25% implementation specific black magic.
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.
I've been reading Boundary Representation Modelling Techniques by Ian Stroud. Not the most approachable book, and I haven't read nearly all of it, but I already found it very valuable.
Subjectively – it's a much more sane environment for programmers than point-and-click UI. If you want parametric design (and you probably do want it unless you're building simple one-off designs), with GUI CAD tools you need to deal with complex constraint systems, and either expensive subscriptions or quirky GUI (or both).
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.
> Parametricity comes essentially built-in, the way variables and functions are built-in to a programming language.
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.
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.
One big feature that I think missing in modern CAD is gamepad support. It’s predominantly a mouse and Ctrl/Shift-WSAD game, with basic joystick accommodations, so to speak.
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.
how can we code a vulkan + cgal + web assembly in a multiplateform cad software ? can we put together open souce bricks to create a cad software ? KiCad afaik is not in rust yet powerfull. I dont care of rust, but how can use latest rendering features from vulkan combined with CGal completeness ? or should we try from scratch in rust a 30 years old problem ? wejave blender and kicad, the other one is missing. Also not sure about a code based cad workflow, really
> 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.
I wish someone would work on a free onshape alternative. They recently banned the use of their free tier for commercial use.
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.
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.
I have a concept in mind, but have no idea yet whether it's going to work out: My idea is to require relationships between geometric objects to always be explicit.
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.
I have no idea whether that will work, but it sounds like you might paint yourself into a corner, so I'd suggest to read about how others maintain geometric robustness. I know this is a tough problem, that's why I asked if this could be done in a separate library, so others can benefit from the work.
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.
I will definitely keep reading and learning, as well as gaining practical implementation experience. We'll have to see how that goes, and what the solution will end up being.
> 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.
