How does this program differ from OpenSCAD? (https://openscad.org, https://github.com/openscad/openscad)
I'm a bit surprised there's no mention of it anywhere in the repository or on the website.
I'm a bit surprised there's no mention of it anywhere in the repository or on the website.
> The most popular Code-CAD application, as far as I can tell, is OpenSCAD. While programming your CAD models, like you would program software, provides a lot of flexibility, the feature set of OpenSCAD is otherwise very limited. This makes many CAD modeling tasks tedious.
> I want to use something more powerful, and that rules out OpenSCAD and a whole bunch of other less-known alternatives.
[1]: https://www.fornjot.app/blog/the-world-needs-another-cad-pro...
I do wonder what kind of limitations the author ran into with OpenSCAD, and why they decided building a replacement code-CAD program was the best way to go.
More power to them, I guess - it'll be cool to see what comes out of this.
It's extremely painful to add fillets to anything by manually designing the geometry. There are a few libraries that try to provide the feature but they are forced to use a pretty inefficient minkowski math that brings your machine to it's knees, and they don't even work that well (can't actually handle every situation). And fillets are not just a nicity you can live without. They are critical all over the place.
The openscad feature set is pretty basic, but there are at least one or two projects that essentially transpile from python to scad. IE, you desribe a model in python with functions that do more powerful things than native scad provides, and it outputs scad code to make that model.
I haven't used those so I can't say more than that about them.
I still use openscad directly for a lot of things and live with it's limitations because to me it's just that huge to be able to check in the model in git and actually diff it and read the file and the diffs directly, and for a whole model to be described in a couple k of human readable text instead of 10 megs of binary or xml.
E.g. how does one place a sphere on top of a box? First you instantiate a box, then you calculate the center coordinate of the sphere and instantiates that one. If you have many objects touching each other, you're going to have a lot of maths there with a lot of variables or functions to reduce repetition.
A better way in my mind would being able to express things like "sphere of radius R has its bottom at center of box.top". Not even a constraint solver is required for this, though that could be nice as well, but would probably introduce its own set of problems :).
This kind of thing could be particularly nice with the interactive OpenSCAD editor that would enable quickly visually determining the locations of the anchors.
So yes it is a constraint solver, but a very simple one, as you can constrain only one parameter, but all others would need to be provided; I meant R to be such a provided value (can of course be a parameter to the function creating the object). Perhaps you could also implement is in a way that R can be provided but expect the code to provide all others.
A more general solver would be nice, but they don't seem trouble-free either. But sure, the syntax could be geared towards future development of such a solver.
Maybe there could be a particular syntax for invoking such a solver that would fit well with the existing system, e.g. an "object" that only has hook points that could be constrained in various manners, and then actual objects would use them as input coordinates.
> I do wonder what kind of limitations the author ran into with OpenSCAD
Lack of bevels/chamfers, no way to refer to existing geometry (to sketch something on a face and extrude that, for example), no constraint-based modeling, weird and limited language. Those are a few off the top of my head.
I don't want to speak badly about OpenSCAD. It's obviously very useful to a lot of people, and I myself keep coming back to it for my own projects (Fornjot isn't ready to replace it). But there are many good reasons to want something else.
> and why they decided building a replacement code-CAD program was the best way to go.
What would the alternative be, in your mind? Trying to join the OpenSCAD project, saying "I want to change everything", would just be rude.
I don't want to fork a big C++ project either, as I don't know the language very well and have no interest in learning it. I'm also not convinced that starting with a fork of something would be better, in the long run. There's value in looking at the problem with fresh eyes.
How do you solve that in "code CAD"? I mean referring to a geometry that's a result of some previous operations, not one that you manually created.
I've written down some preliminary thoughts here: https://github.com/hannobraun/Fornjot/issues/101#issuecommen...
And let me emphasize, these are just preliminary thoughts. I can see cases where what I wrote there won't work, and I'm sure there are many more problematic cases I haven't thought of yet.
There's still a lot of work to do before any of that even becomes relevant for Fornjot. I'll keep thinking about it in the background, but I don't expect to come up with a meaningful solution before I had a chance to really dive into the topic.
CadQuery has its own approach, which I have yet to study in detail: https://cadquery.readthedocs.io/en/latest/selectors.html
Yeah, that is a very weird choice indeed. Brings a ton of constraints to the user (borrow checker for 3d? why?) that have nothing to do with 3D modeling.
I would have understood something like Python or Lua a lot better.
I loosely followed a project of that kind a while ago, I don't quite remember if it was Gluon [0] or Dyon [1]. Not sure if these are still active, or if another competitor showed up in meantime.
___
> The modeling language for Fornjot is Rust. To me, this seems like an akward language to write models in.
I fully agree! Given that Fornjot is written in Rust, starting with Rust as the modeling language was just the most straight-forward option.
But Fornjot is architected to be language-agnostic. Right now, it uses a plugin system based on dynamic linking, and you could plug anything in there that can generate C-ABI-compatible structs (the plan is to replace that with a system based on WASM).
In addition, I've started splitting Fornjot into self-contained libraries[1]. Once that effort is complete, there will be lots of ways to make Fornjot available to other languages.
That said, I think there's merit in having options when using Code-CAD, and Rust is certainly different enough from the typical alternatives to be valuable. I don't think it will ever be the best option for regular CAD modeling, but it might have a niche in infrastructure code that CAD models (written in other languages) use.
In addition to the article that agucova posted, OpenSCAD is also specifically called out in the FAQ: https://www.fornjot.app/faq/
Second question. (Sorry, there isn't a way to link to specific questions in the FAQ yet. I've made a note to add that.)