Website at: rapcad.org
It’s on the releases page.
1 Like
Here’s a link to the GitHub page;
kinda looks like a fork of OpenSCAD. 
Different underlying architecture and some new commands, in particular, commands for writing out text files (well, that’s what I’m interested in)
Two articles:
1 Like
Ah, so it’s a rewrite that abandons the descriptive language for a similar iterative language, and outputs gcode directly?
Something like that — if there’s G-code generation, it’s for 3D printers — I’m having to write/model the code for subtractive work.
1 Like
I worked up a library for modeling cutting like to G-Code at:
It can be loaded in RapCAD by placing it in a location referenced in a line like to:
include <C:/Users/willa/OneDrive/Documents/RapCAD/Libraries/gcodepreview.scad>
(note that backslashes need to be set as forward slashes, or escaped w/ a backslash)
Added two lines to the gcut module:
writeln("G1 X",bx," Y", by, "Z", bz);
writeln("G1 X",ex," Y", ey, "Z", ez);
(that will get uploaded presently)
and it can be written out w/ a one-line command (or batch file) such as:
C:\Progra~1\RapCAD\rapcad.exe gcode.rcad -o null -r rcadgcode.nc
2 Likes
It is a re-write, but I don’t consider that a bad thing. Furthermore, there is no significant rivalry between my project and the OpenSCAD developers, maybe just friendly competition. It’s just two projects exploring the same problem space. So hopefully no ‘Fear of Fork’
1 Like
It intends to support multiple language paradigms like for example C# which supports both imperative and functional programming. I suppose It does abandon ‘pure functional’ programming by allowing the modification of variables, but that’s not the intention.
It doesn’t output gcode directly, but that was one of the design goals. @WillAdams 's work is exploring this ability as a user library, whereas my idea was to support it natively.
3 Likes
Welcome to Maker Forums!
While I have used a lot of OpenSCAD in the past, currently I use FreeCAD for most stuff, so this is mainly curiosity from my point of view…
Can you describe some of the benefits of your approach? Besides giving people an iterative language with which they are likely more familiar, are there things that work better in your approach? From a user perspective, what benefits — or tradeoffs — would an OpenSCAD user find in trying out RapCAD?
Talking about being able to support multiple languages reminded me of Emmett Lalish writing models with his new Manifold kernel directly in C++. Have you seen it?
1 Like
The benefits are:
- programmability — tedious tasks can be automated
- customizability — a design can be provided to non-programmers who can then get a customized result by just tweaking some numbers/settings
- use of non-standard tools such as cove/roundover bits
- 1:1 mapping of machine capability to design — the result of any movement which the machine can make can be used to express the design — it’s not possible to create a design which isn’t machinable
You can see some of the designs which I’ve been working toward at:
and the balance of that site.
1 Like
No, I had not seen it, but it just puzzles me that folks just don’t break down and do all this math as integers, avoiding the need to round at all.
Laudable goal though, and interesting project — in particular, the solution for avoiding the need to pad dimensions so as to avoid infinitely thin geometry is elegant (in the original sense of scientifically correct).
I would love to see it made the back-end of some opensource CAD/3D programming/modeling tool — if I read the GitHub page correctly there’s a Python library?
As for why RapCAD vs. OpenSCAD, I’ll leave that to @Giles to speak to — the big thing for me is being able to write out text files, while having compatibility w/ the OpenSCAD universe (which allows me to use BlockSCAD). Making progress on this at:
Hopefully will be able to make a cut later today.
You would end up rounding anyway because of limited precision. Using integers of very small units is exactly the same as fixed point (vs floating point) and means that you can’t use high performance floating point math acceleration. The fact that a lot of geometric functions involve irrational numbers (including transcendental π) means that any finite representation will have errors which can stack. Using floating point lets you take advantage of accelerated hardware for calculations with trigonometric functions, tremendously faster than the lower-precision results you would get with fixed-point code coded on top of the integer math instructions available to you, which naturally don’t include (approximations of) transcendental functions.
1 Like
Yes, rounding has to happen, chopping off at some integer should work fine — you only need 19 or 20 digits of precision to calculate the diameter of the Milky Way Galaxy to w/in the diameter of a nitrogen atom — some reasonable number of decimal places shifted on pi should work fine.
1 Like
This is one of the things confusing me. I thought @Giles intentionally implemented a similar but not identical language, since changing the language was one of the driving reasons for starting the project in the first place. How much of that universe doesn’t care about the difference? For example, how well does it cope with @nophead’s amazing library?
The point about rounding is that no matter what precision you use, you will have related answers falling on both sides of any arbitrary boundary.
You can use floating point math where the mantissa is the number of digits in the significand and do accelerated math and then round each answer to the integer part, which will lead to rounding errors — but working only in integers gives you the same uncertainty because you are actually still rounding, you are just rounding at every stage of whatever algorithm you are using.
Transcendentals will always do this to you precisely because they are irrational. The ancient Greeks hated this too… 
1 Like
At least w/ integers things consistently fall on one side or the other side.
I always intended RapCAD to be a superset of the OpenSCAD language, but I haven’t been able to avoid divergence since both languages are evolving. A lot of NopHead’s library should work. But when I tested it I think it currently doesn’t because of the way he has structured the project with respect to the usage of include and import, to workaround openscad bugs.
One area where RapCAD diverges from OpenSCAD, relates to the topic you and @WillAdams have been discussing regarding precision. RapCAD uses Mpfr/Gmpq as the backend for all numeric variables and operations meaning there is no loss of precision. This is compatible with the CGAL backend which expects arbitrary precision values for its Exact Predicates Exact Constructions Kernel. This is contrary to OpenSCAD uses floats, up to the point it constructs CGAL geometric objects.
This is by no means the single feature which I would use to differentiate the projects, there are many smaller features like the ‘writeln’ feature that @WillAdams is fond of. I am quite fond of the multithreaded support, and the simplification of the code by using the same CGAL package to support both 2d and 3d.
3 Likes
Cool!
I’m curious; does this allow you to avoid z-fighting?