Our great sponsors
-
Fornjot
Early-stage, next-generation, code-first CAD application. Because the world needs another CAD program.
Mid-term, I want to switch to WebAssembly, to enable web support and open the way for supporting more languages (see #71). Long-term, I think a custom DSL would be ideal, but that's way out of scope for now. It's just too much work, and even if someone else wanted to do it, I don't think it makes much sense to work on it, before the rest of the project has stabilized a bit.
-
I guess there are several ways of achieving that. For what is worth, I recently stumbled upon https://github.com/tversteeg/const-tweaker, which describes itself as:
-
Scout APM
Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.
-
I'm talking about CadQuery. In your github sponsors page you say that available options of programmatic CAD fall short in some aspects, and I believe all points apply to OpenSCAD, but since you didn't mention any of the other available options, I'm not sure if you considered (or knew about) CadQuery, because as far as I can tell, its capable of creating any model possible with a sketch-based approach (kinda like Fusion 360) or with workplanes, supports the usual boolean operations between shapes and many more (sweep, twistExtrude, etc.), has assembly support with constraints, it is easy to install and use (it's possible to install a GUI similar to the OpenSCAD one), it's faster than OpenSCAD (I don't know how fast people want their code-CAD program to be... if they only know about OpenSCAD, it's already an improvement), and it's based on the more powerfull OCCT as opposed to OpenSCAD's CGAL. It's Python, which may be good for some people and not so good for other people, and it is definitely possible to get better performance using another language, but Python is kinda easy to read and write, and there is not much getting in your way while you use it, making the code look very natural (at least in the case of code-CAD uses, I agree not all parts of Python are nice and readable), and they definitely have an advantage by using Python itself instead of an DSL, since you already have the tools to work with the language, both in the editing and in the debugging part of the development. In the case you need something more advanced, you can access the OCCT API directly, or you can create and/or use plugins very easily. These are the things that are already implemented and working. There's still work to be done and even some planned additions, but at this point I think it's possible to say that it's already way beyond OpenSCAD both in features and in overall experience.
-
cadhub
We're out to raise awareness and put CodeCAD on the map. The success of CadHub can be measured by the amount it promotes the use of CodeCAD within the mechanical/manufacturing industry and the strength the CadHub community.
PS.: You may want to contact the guys from CadHub to add Fornjot to their list of code-CAD applications, and maybe take a look at the others I didn't mention if you haven't already. Also I must say that I'm not a dev of CadQuery.
-
Anyways, I've just written that to make sure you know that the "code-CAD scene" or "state-of-the-art" is not OpenSCAD (and I'm not saying you don't know that), and that the ideas you had are really great, but they have already been brought to existence in CadQuery, CQ-Editor (the editor + visualization + debugging GUI for CadQuery), and the (still incipient) Semblage, that started to implement the "hybrid" approach of code-CAD + GUI based on CadQuery. I do believe another code-CAD program won't hurt at all, and there is even the possibility of collaboration between Fornjot and CadQuery and possibly Semblage, but I wouldn't say the world needs another code-CAD program. The world needs first to know about CadQuery and then decide its real needs. I've just read your blog post of your criteria for CAD software, and I really think that (apart from the community part, that requires that the project is known by many people, which seems to not be the case with CadQuery) CadQuery meets them nicely. If there is something I'm missing please let me know, specially if you already knew about CadQuery but it didn't suit your needs. Anyways, good luck with Fornjot!
-
Anyways, I've just written that to make sure you know that the "code-CAD scene" or "state-of-the-art" is not OpenSCAD (and I'm not saying you don't know that), and that the ideas you had are really great, but they have already been brought to existence in CadQuery, CQ-Editor (the editor + visualization + debugging GUI for CadQuery), and the (still incipient) Semblage, that started to implement the "hybrid" approach of code-CAD + GUI based on CadQuery. I do believe another code-CAD program won't hurt at all, and there is even the possibility of collaboration between Fornjot and CadQuery and possibly Semblage, but I wouldn't say the world needs another code-CAD program. The world needs first to know about CadQuery and then decide its real needs. I've just read your blog post of your criteria for CAD software, and I really think that (apart from the community part, that requires that the project is known by many people, which seems to not be the case with CadQuery) CadQuery meets them nicely. If there is something I'm missing please let me know, specially if you already knew about CadQuery but it didn't suit your needs. Anyways, good luck with Fornjot!
