7

I'm wondering if I can take one OpenSCAD object, and cut/splice/split it into two different objects that can then be manipulated independently?

One approach is to duplicate the object, difference it along the cut border with a 3rd object, and then difference the result with itself. This seems overly complex and I suspect I'm missing something

PS - the point of this is that I have a nicely designed part where I need to create an interlock. I want to first cut the part in half, and then create some interlock mechanism

Hamy
  • 263
  • 2
  • 6

1 Answers1

8

Rather than differencing a copy of the object from itself, which is subject to numerical instability, choose a box ("cube" in OpenSCAD terminology), and intersect it with one copy of the object, then difference it from the other copy of the object. This is all easy if you use modules to encapsulate your parts, and it also works with imported STL files.

Specifically, it should look something like this:

module mycut() {
    translate([x,y,z]) cube([w,l,h]);
}

difference() {
    myobject();
    mycut();
}

translate([u,v,w])
intersection() {
    myobject();
    mycut();
}
  • is there any way to create poligon joining splited objects? from first cut facet to second? – eri May 07 '22 at 21:38
  • like `hull`, but using nearest points – eri May 07 '22 at 21:41
  • @eri: You could do it by `linear_extrude` of a `projection` but that's very slow and subject to nasty numerical stability issues. – R.. GitHub STOP HELPING ICE May 08 '22 at 02:25
  • i need same dimentions in 3 stl files, so rotation to XY and back is not good. – eri May 08 '22 at 10:16
  • @eri: Why would 90° rotations mess that up? – R.. GitHub STOP HELPING ICE May 08 '22 at 13:55
  • Maybe. Will try – eri May 08 '22 at 14:31
  • I believe numerical instability is not an issue in OpenSCAD at least in this case because the underlying library uses symbolic algebra (rational numbers) with unlimited precision. Precision only comes into play when exporting (and importing again), or when calculating non-rational functions is such cosine and sine, although results are guaranteed to be consistent (which is nice when matching parts). That said, subtracting an object from itself is probably expensive computationally, so this approach is good as it uses boxes. – Real Aug 17 '23 at 21:01
  • @Real: I don't know the details but OpenSCAD is not exact internally. It uses a horrible mess of different types of math which one is probably better off not asking about. – R.. GitHub STOP HELPING ICE Aug 18 '23 at 01:43
  • See this citation: "As it turns out, OpenSCAD is using the Computational Geometry Algorithms Library (CGAL) for its CSG operations. That amazing library allows for completely generic numeric types, and the type OpenSCAD is using is some voodoo magic “exact” numeric type based on the GNU Multiple Precision Arithmetic Library (GMP)." from [this page](https://ochafik.com/jekyll/update/2022/02/09/openscad-fast-csg-contibution.html) indicates exact rationals usage for unions (and I guess intersections too). – Real Aug 19 '23 at 23:21
  • See more about CGAL [here](https://www.cgal.org/exact.html): "CGAL produces correct results, in spite of intermediate roundoff errors. If three lines meet in one point, they will do so in CGAL as well, and if a fourth line misses this point by 1.0e-380, then it also misses it in CGAL. Situations that are sometimes tagged as "degenerate" (like a 3-D point set actually living in a 2-D plane) are properly handled by CGAL. In fancy terms, this is called the exact computation paradigm, and it ultimately relies on computing with numbers of arbitrary precision." – Real Aug 19 '23 at 23:23
  • @Real: As I told you, OpenSCAD uses a mix of different types of geometry computations, and is getting away from CGAL because it's slow and because the exactness it offered did not actually buy you anything, due to inexactness at other layers. – R.. GitHub STOP HELPING ICE Aug 19 '23 at 23:57