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: