Hacker News Reader

Comment by fps-hero | Hacker News Reader

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.

View on HN

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

In Game Design this can be known as The Door Problem[1] and essentially is why you need a whole company to design good software.

1. https://lizengland.com/blog/2014/04/the-door-problem/

Super comprehensive post. Much better than my comment!

> For example, suppose you add a very simple parameter like setting the diameter of a circle.

This is a solved problem, though! You just do what SolidWorks or Fusion360 (IIRC the most popular CAD packages) do!

>Code as CAD as an idea I believe is flawed.

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.

Love the analogy. Openscad does exist. Openscad has language bindings to at least rust and python. Openscad is already embedded inside freecad.

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.

Are there other shortcomings you have in mind?

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.

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.

Typically we'd call this feature "goto definition"

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.

You wouldn't replace clicking stuff 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.

Oh. You mean with a vtable. Like with OO languages and virtual functions. And it would be just like that except perhaps with borrow checking. ,#rust

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.

I completely agree, and just to point out that the author answered about this below: https://news.ycombinator.com/item?id=30841614

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

Signed distance fields are one approach to this, but it's a very different way of thinking.

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.

Sorry but no. Well maybe you managed to put a new/old name to the problem but SDFs don't solve selecting an edge or a face or a point out of 5000.

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.

https://www.onshape.com/en/resource-center/tech-tips/tech-ti...

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

Already seen it, thanks.

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.

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

>> It is missing a few things, like selecting a face won't let me draw on that face

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.

I appreciate the work that's been put it, I think it's one of the better parametric CAD modellers I've tried.

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.

[0] https://wiki.freecadweb.org/Topological_naming_problem

> Code as CAD as an idea I believe is flawed.

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 ;)

[1] https://scriptcad.com , https://scriptcad.com/paulftw/OpenSCAD.Tutorial

OffTopic:

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.

I played with AnyLogic and its fantastic

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.

[1] https://youtu.be/Snx1R42JnBE?t=95

It's a simulation software that allows you to animate the systems you are modeling, so you're right that it isn't a CAD program.

This sounds interesting, out of curiosity... What is it that you're trying to do?

Just a toy model for improving electrification of heavy transport. Higher utilization and careful scheduling brings down capex and opex.

Looks feasible. But i am not an electrical or production engineer.

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!

> How hard is it to even simply copy the time tested work flows in proprietary software.

A straight copy would be sued out of existence.

Reply on news.ycombinator.com