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.
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.
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.
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.
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.
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.