RapCAD 1.0.2 just released --- OpenSCAD alternative, can write out files

CAD & CAM Tool Chain
8

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
9

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
10

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
11

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
12

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
13

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.

14

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
15

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
16

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?

17

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… :grin:

1 Like
18

At least w/ integers things consistently fall on one side or the other side.

19

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
20

Cool!

I’m curious; does this allow you to avoid z-fighting?

21

does this allow you to avoid z-fighting?

Yes, although this is really because of the CGAL backend. If I recall correctly OpenSCAD only has z-fighting issues when using the preview mode that uses OpenCSG. It’s possible that geometry with rational size values has rounding errors in OpenSCAD not present in RapCAD.

1 Like
22

@Giles, the rapcad.org web site has almost no content, just a couple of general paragraphs that could just as easily describe many other packages, including OpenSCAD. That’s why I was kind of confused about how RapCAD is different; it didn’t seem that I could answer my own questions by reading it.

I note that the build instructions point at a git repository that doesn’t respond:

RapCAD

git clone git://git.rapcad.org/rapcad

cd rapcad &&
qmake &&
make

Incidentally, on Fedora, it’s qmake-qt5 because Fedora also has qmake-qt4 available.

RapCAD doesn’t seem to honor $fn which I used for angular resolution a lot. Also maybe it isn’t as… flexible about the idea of a cylinder as OpenSCAD is?

I grabbed a random OpenSCAD file I’d used recently to test with RapCAD.

od=72;
id=64;
cd=48;
bcd=od+15;
cone_h=20;
height=100;
h_lip=4;
$fn=180;


difference() {
    union() {
        cylinder(d=od, h=height+h_lip);
        cylinder(d1=bcd, d2=od, h=cone_h);
    }
    translate([0, 0, height]) cylinder(d=id, h=5.1);
    translate([0, 0, height-cone_h]) cylinder(d1=id, d2=cd, h=cone_h+0.01);
    translate([0, 0, -0.01]) cylinder(d=id, h=height-cone_h+0.02);
}

In OpenSCAD, it looks like this:

image
image565×754 15.7 KB

In RapCAD, it looks like this:

image
image565×754 13.9 KB

23

The rapcad.org web site has almost no content.

Yeah it needs work. I only recently re-registered the domain and added hosting on github pages. The original website content was moved to RapCAD – Giles Bathgate

I note that the build instructions point at a git repository that doesn’t respond … Incidentally, on Fedora, it’s qmake-qt5 because Fedora also has qmake-qt4 available.

I’ll update the build instructions.

RapCAD doesn’t seem to honor $fn which I used for angular resolution a lot. Also maybe it isn’t as… flexible about the idea of a cylinder as OpenSCAD is?

It does, it’s just that the special variables don’t have parent scope, so you just have to pass it into each module cylinder(d=od, h=height+h_lip,$fn=$fn); That is a bug, but it’s never been much of a problem, because often that’s how I find people use it in OpenSCAD anyway. I should fix it though.

A better variable to use is $fe, this works out an $fn that gives an error within the tolerance of the resolution of your 3d printer so for example, I use $fe=0.01 for my prusa mk2, which gives nice results.

There is a prism module which takes a sides parameter, which is my preferred way for creating n sided prisms instead of overloading cylinder.

cylinder(d1=id, d2=cd…

That’s an oversight, when I implemented cylinder OpenSCAD didn’t have diameter parameter support at all. I implemented a d parameter, but not d1 and d2. That said r1 and r2 for cylinder do work.

2 Likes
24

Maybe slightly off-topic, but I have recently abandoned OpenSCAD in favour of CadQuery (CadQuery 2 Documentation — CadQuery Documentation).

The primary advantages that I see are:

  • Uses a BREP representation internally (as opposed to CSG used by OpenSCAD) - this means that stuff like chamfers and fillets are supported directly, and that you can export in e.g. STEP format as well as STL
  • Python is a much better language than the scripting language used by OpenSCAD

It does have a steeper learning curve than OpenSCAD.

25

I wanted to like CADquery — got confused by the initial version being a FreeCAD Workbench, then moving to a stand-alone project.

The problem is, like all-too-many Python projects it’s hard to install/run — I’d like to love/use Python, but it’s hard when the fact that there are myriad package systems for it is a running joke:

I know cpan.org is already taken up by the Perl folks, but Python really needs something to simplify all this.

1 Like
26

Python is pretty easy on Linux since it can be completely maintained via PATHs and user filesystems.
A number of utilities to make this really easy are VirtualEnv and Conda and since Microsoft hired the primary Python dev years ago surely they’ve made it easy to manage on their Windows OSes.

27

I recommend the standalone CQ-editor package: Release 0.2 · CadQuery/CQ-editor · GitHub