<p>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.</p>

<p>Specifically, it should look something like this:</p>

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

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

translate([u,v,w])
intersection() {
    myobject();
    mycut();
}
</code></pre>

CC BY-SA 4.0
2022-05-07T21:38:34.970Z
is there any way to create poligon joining splited objects? from first cut facet to second?
eri
CC BY-SA 4.0
2022-05-07T21:41:58.647Z
like `hull`, but using nearest points
eri
CC BY-SA 4.0
2022-05-08T02:25:40.147Z
@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
CC BY-SA 4.0
2022-05-08T10:16:45.677Z
i need same dimentions in 3 stl files, so rotation to XY and back is not good.
eri
CC BY-SA 4.0
2022-05-08T13:55:58.150Z
@eri: Why would 90° rotations mess that up?
R.. GitHub STOP HELPING ICE
CC BY-SA 4.0
2022-05-08T14:31:20.683Z
Maybe. Will try
eri
CC BY-SA 4.0
2023-08-17T21:01:39.153Z
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
CC BY-SA 4.0
2023-08-18T01:43:21.857Z
@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
CC BY-SA 4.0
2023-08-19T23:21:22.457Z
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
CC BY-SA 4.0
2023-08-19T23:23:19.583Z
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
CC BY-SA 4.0
2023-08-19T23:57:30.800Z
@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
CC BY-SA 4.0
2019-06-23T17:22:56.360Z
2019-06-24T15:15:30.327Z
2019-06-24T15:15:30.327Z
R.. GitHub STOP HELPING ICE
<p>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? </p>

<p>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</p>

<p>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</p>

<openscad>
Is there an easy way to split models in OpenSCAD?
Hamy
# Is there an easy way to split models in OpenSCAD?

(Asked by: username_0 on 2019-06-23)

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

**Tags:** openscad


---

## 1 answers

### Answer by username_1 on 2019-06-23. Score: 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();
}

```

> **Comments:**
> **username_2**: is there any way to create poligon joining splited objects? from first cut facet to second?  
> **username_2**: like `hull`, but using nearest points  
> **username_1**: @username_2: You could do it by `linear_extrude` of a `projection` but that's very slow and subject to nasty numerical stability issues.  
> **username_2**: i need same dimentions in 3 stl files, so rotation to XY and back is not good.  
> **username_1**: @username_2: Why would 90° rotations mess that up?  
> **username_2**: Maybe. Will try  
> **username_3**: 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.  
> **username_1**: @username_3: 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.  
> **username_3**: 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).  
> **username_3**: 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."  
> **username_1**: @username_3: 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.  

---

