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.

Hey, author of Fornjot here.

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

> no way to refer to existing geometry (to sketch something on a face and extrude that, for example)

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.

> 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

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.