Hi Michael,

thank you for the answer but what I was asking is not preview artifact or a way to tweak my design to get around a trap in OpenSCAD. (Preview is not an issue and as I wrote I have found a way to get the result).

The final geometry is valid but OpenSCAD failed to output it, so I see this as a bug, no matter how difficult it is to fix.

Well, anyway, now it is off my hands.

Thank you,
Tim

From: Discuss discuss-bounces@lists.openscad.org on behalf of MichaelAtOz oz.at.michael@gmail.com
Sent: 24 July 2019 07:43
To: discuss@lists.openscad.org
Subject: Re: [OpenSCAD] CGAL error depends on order of unioning

Shaporev, Timur wrote

I had a look at the code.
With the combination of operations, mostly lined-up at the same boundaries
you are prone to getting edges of two objects aligning, which creates
non-manifold geometry.
At such high resolution you increase the chances of such common edges
aligning.

Firstly, the preview artefacts you have can be fixed by using convexity=10
in linear_extrude (in two places), it makes looking at the detail easier.

At first I suspected the four quarters probably had the symmetry to cause
this.
But not this time.
It is an art you learn, but I look for points of convergence.

Second try was here:
http://forum.openscad.org/file/t359/Capture_ring_centre.jpg
The middle edge of the inside of the central ring hole, that aligns with the
surface of the back of the face.

Try this as an example

#cube([40,40,10]);
translate([5,20,20])
rotate([0,90,0])
cylinder(h=30,r=10,$fn=12);

F6 gets "UI-WARNING: Object may not be a valid 2-manifold and may need
repair!"

So in fail1.scad the easy way to fix it is to rotate that cylinder around
z-axis a small amount, so the line is not co-incident with that face.

difference() {
union() {
// assemble them back again
quarter(); mirror([0,1,0]) quarter();
mirror([0,0,1]) {
quarter(); mirror([0,1,0]) quarter();
}
rotate([0,0,1])    //
<--------------------------------------------
rotate_extrude()
hull() {
translate([Rmid,ring_min_width/2-Rth]) circle(Rth);
translate([Rmid,Rth-ring_min_width/2]) circle(Rth);
}
hull() {
translate([Rmid, yl,zl-Rm]) sphere(Rth);

With that F6 completes without error.

Admin - email* me if you need anything, or if I've done something stupid...

• click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”  Fight it! http://www.ourfairdeal.org/  time is running out!

Sent from: http://forum.openscad.org/

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

Let me put it different way: is it documented anywhere

1. that all intermediate results should be manifold and
2. exact order of operations (note that enclosing quarters in additional
   explicit - or implicit - union like in 'good1' resolves the issue).
   If these are documented then it is my fault that I did not read it
   (though I'd like to have the issue fixed as an enhancement).

But as far as the final geometry is correct I see this as a bug
(though I do understand that it could be too hard to fix).

And, finally, thank you for the explanation - it is helpful.

:-)
Tim

On 7/23/2019 12:36 PM, nop head wrote:

Basically everything that needs to be rendered to a solid has to be
manifold, including all the intermediate steps, because the library used,
CGAL, only handles manifold objects. It isn't a bug, it is designed that
way.

It won't change unless OpenSCAD stops using CGAL for its CSG operations.
Note that CSG operations over manifold geometry is not closed, so no matter
what library is used you can make non-manifold geometry with union,
difference and intersection. STL files can not represent non-manifold
geometry and 3D printers can not print it. These things will never change.

On Wed, 24 Jul 2019 at 14:00, Tim V. Shaporev tim.shaporev@auriga.ru
wrote:

Sigh.
The final geometry is valid, so no issue with either STL or 3D printer.

And I know the way to fix this particular issue using CGAL
(though it seems to be too slow for practical usage).

On 7/24/2019 4:22 PM, nop head wrote:

nop head nop.head@gmail.com written:

That is not precisely true. When we have just one polyhedron() primitive,
it can generate a STL file even if the polyhedron is not a manyfold.
For instance:

polyhedron([[0,0,0], [1,0,0],[0,1,0]],[[0,1,2]]);

is just a triangle and it renders fine and generate a STL file. Even
polyhedron() with self-intersection are accepted by CGAL when are alone.

STL files can not represent non-manifold geometry and 3D printers can not

That is not also true. The above example shows that OpenSCAD is able to
generate non-manifold STL files. After all, STL files are just a soup of
triangles.

I don't agree either that non-manifold can't be 3D printed. The object
bellow is printable:

union()
{
cube(1);
translate([1,1,0]) cube(1);
translate([0,0,0.9]) cube(2);
translate([0,0,-1.9]) cube(2);
}

and it will be solid in the sense that it will not fall apart easily. It
can't be rendered by OpenSCAD (CGAL) as is but it could be represented in a
unique polyhedron and then a STL file could be generated by OpenSCAD.

Unless you do a CSG operation CGAL isn't involved. So yes you can create
any old polyhedron and make an STL but only manifold STLs allow the
topology to be reconstructed unambiguously.

When I said you can print a non-mainlined object I mean they cannot exist
in reality so can't be printed. Yes you can send a non-manifold STL to a 3D
printer and something may come out, depending on the slicer, but it will
always be a manifold object and not what the file represents.

On Wed, 24 Jul 2019 at 19:31, Ronaldo Persiano rcmpersiano@gmail.com
wrote: