The union seems to make up extra vertices. If I show the cylinder on its
own or the hull on its own the vertices are in the same place. Also they
are as should be with F5 but F6 introduces new vertices that should not be
there. I tried to distil it down to a simple example but that works fine.

On 3 January 2016 at 12:17, nop head nop.head@gmail.com wrote:

I guess we could do this as a special case. Note that 4 vertices in floating point aren’t guaranteed to be planar, but there’s a good chance they are. CGAL is particularly picky about planarity and we have to triangulate whenever CGAL complains.

-Marius

With linear_extrude surely the top vertices have exactly the same x,y
coordinates as the bottom and just differ in Z, regardless of the
representation?

On 3 January 2016 at 16:34, Marius Kintel marius@kintel.net wrote:

Good point. If we also disregard scale, that would indeed constitute a special case we could rely on.

-Marius

I am trying to get rid of degenerate triangles in the STL. I think they
come from these extra facets and vertices. However I now think it may be a
bug in CGAL union.

Here is the result from my code with a lot removed. There are extra facets

​
Here is my simple test code to re-create the bug, but it doesn't happen.

$fa = 5;
$fs = 0.5;

union() {
cylinder(r = 4, h= 100);

linear_extrude(height = 10) hull() {
        circle(4);

    translate([30, 10, 0])
        circle(4);

    translate([10, 30, 0])
        circle(4);
}

}

This is what it should look like because the vertices on the top and bottom
of the cylinder should exactly match those of the rounded corner,
regardless of number representation as they are all created by circle or
cylinder with the same parameters.

On 3 January 2016 at 17:04, Parkinbot rudolf@parkinbot.com wrote:

On 03. jan. 2016 17:42, Marius Kintel wrote:

This will fail (generate nonplanar quads) if you apply the right skewing
with multmatrix.

Carsten Arnholm

How does it handle cylinder then?

On 3 January 2016 at 19:36, Carsten Arnholm arnholm@arnholm.org wrote:

On 03. jan. 2016 20:51, nop head wrote:

Better than what i expected, or so it it seems :-) I may have been to
quick. I tried things like this:

multmatrix([
[1, 0.8, 0, 0],
[0.2, 1, 0.95, 0],
[0, 0, 1, 0],
[0, 0, 0, 1]]) {
cylinder($fn = 12, h = 100, r1 = 20, r2 = 20);
}

From the looks only, it does indeed seem the quads remain planar.
However, there could be numerical issues.

Carsten Arnholm

I have boiled my bug down to this: -

$fa = 5;
$fs = 0.5;
tube_r = 4;
x = 38.8808;
y1 = 59;
y2 = -50;

union() {
translate([x, y1,    0])
difference() {
cylinder(r = tube_r, h= 100);

        translate([0, 0, 99]) // small hole in the top
            cylinder(r = 1, h = 2);
    }

linear_extrude(height = 10) hull() {
        circle(tube_r);

    translate([x, y1])
        circle(tube_r);

    translate([x, y2])
        circle(tube_r);
}

}

Which gives

​
Simply commenting out the small hole in the top of the cylinder gives this:

​
So it looks to be some sort of numerical problem swapping between CGAL and
homebrew representations. I guess removing the hole in the top removes a
trip through CGAL and the circle coordinates remain exactly equal. However
I can't understand where the extra circle vertices come from as they are
not numerically close to the real vertices.

On 3 January 2016 at 20:37, Carsten Arnholm arnholm@arnholm.org wrote:

And here is an even simpler version just unioning coincident cylinders.

$fa = 5;
$fs = 0.5;
tube_r = 4;
x = 38.8808;
y = 0;

union() {
translate([x, y, 0])
difference() {
cylinder(r = tube_r, h= 100);

        translate([0, 0, 99]) // small hole in the top
            cylinder(r = 1, h = 2);
    }

    translate([x, y])
        cylinder(r = tube_r, h = 10);

}

With X = 0 there is no problem but other values give various extra vertices.

The version I am using is 2015, 5, 16

On 3 January 2016 at 20:49, nop head nop.head@gmail.com wrote:

I am not suprised about linear_extrude(). What really suprises me is that the
basic implementations of cylinder and cube do use squares. This is not
self-evident. I mean, if you start like this, you could also allow for
convex n-polygons as planar thing (as you can do it VRML). I guess this has
some historical reasons.

BTW, your problem has implementational AND numerical backgrounds. You get
what you want, if you give union() some "help":

--
View this message in context: http://forum.openscad.org/Unnecessary-triangulation-in-linear-extrude-tp15429p15450.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

In that case there are just extra edges between existing vertices, which is
not too surprising. With this version the extra vertices appear at $fn = 32;

$fn=32;
translate([10.1,0,0]) {
cylinder(r = 4, h= 20);
translate([0, 0, 100]) cube(); //dummy
}
translate([10.1,0,0]) cylinder(r = 4, h = 10);

On 3 January 2016 at 23:05, Marius Kintel marius@kintel.net wrote:

I tried it in an old version of OpenScad, 2013.06, which I assume only does
F6 in CGAL. That doesn't have the problem.

Is it perhaps that translate produces a different result when the object it
gets is from CGAL?

Another numerical issue I have noticed is when I generate Mendel90 on a
different PC, but with the same source files and the same old OpenScad
binary then some of the STL files are different. When I examined a simply
example I found one vertex on a circle had a different Y ordinate that
differed by one in the last floating point digit. One is an Intel Core2 Duo
running 32 bit XP and the other an Intel Core i7 running 64 bit Win7.
Perhaps I am naive but I thought IEEE floating point maths was supposed to
give consistent results.

On 3 January 2016 at 23:05, Marius Kintel marius@kintel.net wrote:

Another test that shows CGAL is OK is this:

fn=11;
translate([10.1,0,0]) {
cylinder(r = 4, h= 20);
translate([0, 0, 100]) cube(); //dummy
}
translate([10.1,0,0]) {
cylinder(r = 4, h = 10);
translate([0, 0, 100]) cube(); //dummy
}

This gives the correct result showing if both cylinders pass through CGAL
before being unioned they have numerically equal coordinates. When one is
translated before it gets converted to CGAL format the union generates
extra vertices. I think these are simply where two slightly different
planes meet.

On 4 January 2016 at 08:31, nop head nop.head@gmail.com wrote:

BTW, what precision does OpenScad use for evaluating expressions in the
source code?

On 4 January 2016 at 08:42, nop head nop.head@gmail.com wrote: