alt Hacker News> You must ensure there is enough overlap between these three separate parts so the resultant object is a single surface and not three separate ones.
(Post author here.)
This was a very weird thing to me I ran into and have thus far just sort of... accepted.
In Fusion, and other CAD software, if I have two faces end at the same point, unless I've specifically said to create them as separate bodies, they are joined, because they share a plane.
In OpenSCAD, in the tutorial, it has you extend an object 0.001 to ensure they overlap. To quote:
> In the example above, the second cube sits exactly on top of the first cube. This is something that should be avoided, as it’s not clear to OpenSCAD whether the two cubes form one object together. This issue can be easily solved by always maintaining a small overlap of about 0.001 - 0.002 between the corresponding objects. One way to do so is by decreasing the amount of translation along the Z axis from 10 unit to 9.999 units.
This struck me when making the example in my post. In line 47 I specifically add 1 to heightCompartment to ensure the opening extends past the top of the main body. If I didn't do that, this happens during preview: https://imgur.com/a/Amc1dK6 (That's an exported image from the latest nightly of OpenSCAD.)
But it doesn't happen during the actual render?
Still, that just feels... like there's something going on with a floating point value or something which, programatically, is probably correct... But from the perspective of someone trying to design something feels Very Wrong. Because I have a 20mm high box, I subtract a 19mm high box from it, starting 1mm up from the base. Why shouldn't the top be open? Why is it acceptable for it to be maybe kinda open but broken by design?
Floating point numbers are not closed under addition. They are not real numbers and not rational numbers. FP is on a grid whose size changes the farther you get from 0,0. For example 0.1 doesnt exist in fp nor does any number not representable by binary fractions. Also its a quirk of opengl and most 3d renderer to get issues when one surface coincides with another so the preview renderers like the little bumps. Also the underlying CGAL rendering kernel can be problematic when planes are almost nearly coincident but not one hundred percent. Finally OpenSCAD has an internal grid it tries to snap things to which can also cause issues. Not sure if the new Manifold renderer has these issues but in general the loss of info from ascii decimal to FP is the source of most of the problem. Those professional cad programs have enormous resources behind the scenes to make that stuff appear easy when its actually very complex and basically an illusion. Rotating anything using sine and cosine instantly loses information so planes with more than three points become non planar ever so slightly. So this assembly you made with “two surfaces touching” is not touching after rotation due to sin eing transcendental function simulated on a computer with finite time and memory. For example. These fancy CAD systems all have ways to deal with this.