The boolean engine used is xcsg https://github.com/arnholm/xcsg based on Carve https://github.com/arnholm/carve
Documentation sections such as Datatypes in AngelScript, C++
Object handles to the application and Memory management are not features I want in a declarative language: accepted wisdom is to use the least powerful tool for the job. Edge cases should be dealt with as the exception, not burdensome as a rule which can be convention over configuration.
I would like to suggest something lighter. https://gist.github.com/globalcitizen/ded2ba77b48f75f2813f15...
This would be simpler, less keystrokes, shorter and more legible.
OK, but why?
Edit: Why not is because of the mentioned norm, ie. use the least powerful tool for the job. Alternatively stated, KISS. Asking programmers to delve in to a new set of assumptions, limitations and so on that could otherwise be avoided is creating friction. Unless there is an explicit reason for doing so, it does not seem wise.
Further edit: You make a good point about thought process, and I think graphviz is a clear example of a popular tool where the friction you mention between application-specific concerns and restrictive declarative syntax often lies, sometimes complicating an overall workflow.
AngelCAD does not try to impose a specific programming paradigm, it offers well known syntaxes and techniques for problems that can be complex. Of course, a user can choose to use only a subset of the language, this would be a typical starting point. Then with more experience and if the need arises, one can employ OO techniques with user defined scripting classes etc.
The user defines what is simple enough.
Edit1, reply to below comment. What is explained in AngelScript documentation is that the user does NOT have to worry about memory management. It is automatic.
Another thing is that I chose to use an existing language instead of creating a new one. I chose AngelScript because it was very easy to integrate with the implementation language (C++) and because it existed, was well documented and had all the features I wanted.
You could argue that one could choose another existing language (Python or whatever), and that is fair enough. The design is such that the language interpreter is entirely separate from the boolean engine (they are different executables), so all you have to do is implement the AngelCAD features in the scripting language you prefer and give it to the world. That is essentially what I did.
The point, ex comments, is that it removes all the crap about scenes and setup and output and memory and types. Nobody cares, human time has value, machine time is free, and it's 2020.
Also, it's more expressive (more meaning in less space), which is a great feature.
I disagree about types, it's great to actually know what you're dealing with and instantly know what operations you can do on objects without deep diving into layers of code and outdated documentation (the "ruby way"). Also I don't know if you have actual experience with CAD design but machine time is definitely not free there.
A declarative syntax seems better in theory but in practice if forces clunky syntax as soon as you are dealing with slightly deep hierarchies. Imperative syntax is just simpler, you can manipulate objects directly, pass them around to functions, the "object" paradigm makes sense here.
Heh, actually I run a robotics company. There are multiple people working for me full time doing CAD design. I would argue that delays due to tedious input in an industrial fabrication context are more expensive as you are not just using human time but also blocking on supply chain and 'machine time' scheduling, and ultimately potentially all business expenses. For this reason I do not understand your point.
You could have done scripting for STEP models.
STEP is an entirely different domain.
STEP is not an entirely different domain.
Though, I really wish people would do something like this built on Julia (or perhaps even Nim). There's nothing too magical IMHO in what I can see of AngelScript or OpenSCAD script that couldn't be done with macro transformations. Then you'd get a real language with better documentation, semantics, etc and could integrate with a larger echo system.
I'd love to have an ecosytem in Julia where you could build 3D models, then plug them into a FEM model feeding the results into a deep neural net.
The software was seriously clunky, but it has a lot of potential.
Text-based CSG definitions are faster, clearer and easier than all these GUI tools. They are also diffable, scriptable and regexable.
Nothing wrong with GUI CAD tools, but there are many of them already and some of them are huge and difficult to learn IMHO. Those who want a traditional GUI CAD tool should probably try something different, but AngelCAD is really not that hard to learn.
I wanted scripting with a strongly typed object oriented language, and I could not find one. So I created AngelCAD.
I'm actually pleased to hear about this, since I find my patience with most 3d programs is very short, and I really have a need currently for being able to create 3d objects using CSG that I can work with hopefully for a game I'm making.
One thing I've been waiting in Julia is a nice GUI toolset, but they all seem to be broken or incomplete. Julia's static compile ability is also lacking currently. My take is that there's an opening in the market for a good CAD program based on an open source modeling engine. Sell the GUI for money (or an enterprise polished version), but make the core engine and modeling open source and with a good API. It'd be a small market slice (e.g. grad students, small startups), but perhaps it could gain mindshare over time.
There is still an opportunity for a good opensource CAD program but only because the existing ones such as FreeCAD need an overhaul. Forking FreeCAD and fixing the glaring flaws would be significantly less work.
The FreeCAD project is stagnating. There is an issue about someone wanting a visualization of the internal coordination system of a datum plane. That visualization already exists in other parts of FreeCAD but when you go through the forum posts you see that one of the users is blocking this absolutely microscopic change because of mathematical purity. Mathematically speaking planes don't have an orientation and therefore this feature would not make logical sense and you should use a local coordinate system if you want to change the orientation, including visualization. Except FreeCAD implements a datum plane with an internal local coordinate system. This results to weird things like sketches being rotated by 90°. There is no way to know in which direction your sketch has been rotated without the requested visualization so even if you wanted you can't just reattach your sketch in the correct orientation. You first have to mark the "up" direction by drawing an arrow in the sketch and then orienting the sketch with the help of that arrow. There is no need to talk about mathematical purity when the software has already broken it and makes the user suffer as a result.
I use openSCAD for 3D printing, but its limitations become quickly obvious. All surfaces are a series of 4 sided polygons. I would prefer to be able to define smooth curves and only choose the resolution on export. The language itself is a trip to wrap your head around. I regularly need to keep 4 levels of transformation in my head when working on an individual piece. There are better ways. I will need to look at AngelCAD.
I haven't worked in this space for 15 years so this might have changed, but back then no one used CAD tools for serious FEM modeling. The fundamental reason is that the requirements for a good FEM mesh are different from a good geometry mesh. Just one example from my work back then is that we had to follow modeling guidelines which required the use of quads with balanced aspect ratio only. Use of triangles had to be justified. We basically remodeled everything in the FEM software (PATRAN, FEMAP and lots of in-house tools in our case).
This is actually a very active area of research (at least 5 years ago when I worked in simulation). There were papers on voxel methods, Fourier analysis (move the model to the frequency domain and filter out small details that are hard to mesh and affect convergence) to automatically réparé CAD models to an FEM environment :) I have no idea how things have advances since, but it looked nowhere near usable in the industry half a decade ago.
Actually, maybe a statistical algorithms would be suited to simplify models should one have a proper dataset to train on, because it's very hard to do analytically.
The modelling is currently done in a language called EXPRESS but this is changing to use SysML tools and then transforming a SysML model to an XML schema using XSLT.
Maybe have a look at some of the Open Source CAD systems with full STEP capabilities like BRL-CAD  or Open Cascade Technology . They contain C++ class definitions for each of the classes in supported STEP models as well as code to read and write exchange files, basically serializing and deserializing object instances.
The STEP C++ classes in a system like the two mentioned are typically machine generated from the standardized model, the tool that is used in BRL-CAD to do this is stepcode .
The way I see it, if one of those tools really wants to succeed in the industry, it needs to have a GUI for that group of end-users. I think one way this could be nicely achievable with a JSX(-like) markup system, where components can be easily GUI editable as long as you don't have any custom code in them (just like low-code React editors do it).
There is some overlap but it's not that big. OpenSCAD is useful if you can describe your model as an algorithm. FreeCAD is useful when you want to define your model visually.
I don't think one can say either of them is strictly better than the other because they are not quite the same.
However it's easy to see how avoiding the need for a constraint solver significantly reduces the complexity of the software.
But OpenSCAD’s approach hit a wall quickly for me. Trying to figure out the distances for new objects was a PITA. It would be nice to have a simple GUI tool for placing an item by inserting the proper code. Ideally you’d be able to link changeable parameters in the GUI to code variables and be able to do things like show/hide in the GUI, or even a repl.
In the meantime another possibility might be to write a code generator for the scad language.
That being said, those are clearly "toy" level of complexity and I haven't tried it out.
That said, a recent post on Reddit in r/openscad mentioned designing an entire car to do the Pike Peak challenge in Colorado.
We have a lot of tools and methodologies available. Picking the right one needs care and attention to detail. It's the same as the other "real world": I know my way around metal and wood working equipment and I can do simple welding. My carpentry is good first and second fix grade but not cabinetry, and I can weld stuff together, sometimes without melting both objects.
I can design bridges and roads as well and they may work fine ...
Trying to design 3D objects by writing code is using the wrong tool for the job. You can make cool curvy things. Now try to design an auto suspension. Or a head.
I eventually found CadQuery (https://github.com/CadQuery/cadquery) which can create non-mesh STEP files. It’s a lot rougher then OpenSCAD but usable.
For STLs there are a number of 3D CAM tools: MeshCAM, pyCAM, FreeMill, or importing the file into Autodesk Fusion 360 and using its CAM tools.
List of other options at: https://wiki.shapeoko.com/index.php/CAM#3D_2 and https://wiki.shapeoko.com/index.php/Commercial_Software#3D_C...
I don't know Julia but you can build a front end to the AngelCAD boolean engine and by-pass AngelScript if you so prefer. Flexibility is a key idea.
I used to program AutoLISP routines in AutoCAD decades ago. Creating geometry strictly from LISP without using the GUI was amazing.
One I tried that was striving to make the PL uniform across CAD packages is Rosetta . It worked with Rhino and AutoCAD, and you could get it to work with others.
In this stage it has no chance of being packaged. I started converting it to autotools, but it's long way to go.
I know Python is popular, and there is nothing to stop you from developing an alternative front end in Python or any other language of your liking, and still use the AngelCAD boolean engine, just implement the xcsg protocol https://github.com/arnholm/xcsg/wiki
Plus pure FP code should time-independent in its evaluation, so it doesn’t take a genius to imagine the benefits of (safely!) introducing a time axis on top of that. Procedural generation, animation; great potential there.
This is not all idle speculation, BTW: I wrote a semi-declarative DSL for 2D artwork production that blew its traditional imperative rivals out of the water while also being easy enough for non-programmers to use. So I know there’s potential there, and I’d be fascinated to see what kind of language someone with a mind for 3D math could shape for the task. Plus as a trained sculptor turned automation junkie who can’t stand GUI-based 3D drawing apps (they just don’t fit my head), I’d love to try something with a language-based interface instead.
- PostScript, a complete concatenative programming language for 2D drawing (incidentally, Adobe used to do a vector-based 3D drawing tool too: https://web.archive.org/web/19991127092153/http://www.adobe....)
- Alan Kay’s Maru/Nile/Gezira stack (or how to write a full 2D graphics engine in 500LOC: https://news.ycombinator.com/item?id=10540031).
> AngelCAD is a powerful open source 3D solid modeller based on the Constructive Solid Geometry (CSG) modelling technique, expressed in the AngelScript language. The software creates 3D models in STL or other file formats.
However - I can't see if there's anything out of the ordinary about the app. I'd like to have seen some info on what makes this exceptional.
"AngelCAD is a powerful open source 3D solid modeller based on the Constructive Solid Geometry (CSG) modelling technique, expressed in the AngelScript language. The software creates 3D models in STL or other file formats."