Argh, yes, I think this is a bug triggered by an optimization trying to avoid using CGAL where not necessary.

-Marius

I though that putting render() around it to force CGAL during F5 would fix
the problem but it doesn't.

The problematic code is a stack of linear extrudes unioned together.

On Wed, 2 Jan 2019 at 21:20, Marius Kintel kintel@kintel.net wrote:

The problem seems to be caused by very close edges in a stack of polygons
with different numbers of vertices.Each polygon has its radius defined by r
/ cos(180 / fn) so that the flat sides line up. But of course they don't
line up exactly when 180 / n is an angle that makes cos return an
irrational. Making each one smaller by 1/128 so they never line up exactly
AND adding a render() around the stack fixes it.

This is for generating hanging holes that print in mid air without support
material.

[image: image.png]

I think something must snap the vertices and break the topology during F5
and that gets cached and breaks F6. I don't understand why render doesn't
fix it though. It seems geometry generated by render() is different under
F5 than it is with F6 but I thought render() was supposed to do the same as
F6 for that sub tree. Perhaps that is something that could be fixed, so at
least just render() is a work around. I think the underlying problems is
using three number systems and not doing topologically aware conversions
from one to another.

On Wed, 2 Jan 2019 at 23:35, nop head nop.head@gmail.com wrote:

Actually when I eliminated all the nearly coincident edges it don't need a
render().

On Thu, 3 Jan 2019 at 08:53, nop head nop.head@gmail.com wrote:

Doing F6 before F5 isn't a workaround either because although it keeps CGAL
happy the exported STLs are broken according to NetFabb, presumably due to
truncating to floats. Basically all vertices, whether specified or
generated need to be either exactly coincident or sufficiently difference
that they remain different in all number representations, rational, double,
float and fixed point and when snapped to the dreaded grid.

In fact, is the grid snapping the major problem with OpenSCAD? How can it
be correct to simply snap vertices to a grid? If they start distinct they
need to stay distinct. What problem is the grid trying to solve?

On Thu, 3 Jan 2019 at 11:20, nop head nop.head@gmail.com wrote:

On 1/3/19 7:18 AM, nop head wrote:

Probably one I stumbled over a while ago:

https://softsolder.com/2015/01/02/openscad-quantized-vertices/

The discussion & pull:

https://github.com/openscad/openscad/issues/1107

https://github.com/openscad/openscad/pull/1115

Perhaps the state of the slicer art has made quantization irrelevant,
but … this may not be a solve-able problem in OpenSCAD.

--
Ed
https://softsolder.com

The main issue as I see it is every time you quantise the vertices some
formally distinct ones may merge and that breaks the topology. That happens
when STL files are written because they use floats and every other vertex
representation in OpenSCAD is higher resolution.

Quantizing the vertices on a grid courser than a float seems only to make
that problem more likely, make it happen earlier and doesn't fix anything.
What am I missing?

Basically it seems that users have to ensure their vertices are not closer
than the grid or they will get CGAL errors or generate STL files with self
intersections or degenerate triangles. This is very difficult because the
2D irrational vertices can never be made to match the 3D ones due to being
represented in fixed point, versus doubles or CGAL rationals. So a linear
extruded circle does match a cylinder exactly for odd numbers of vertices.
So any CGS between them is likely to generate errors.

I think it could be fixed by making sure that whenever vertices get
quantized they are checked to make sure ones that were separate are not
given the same value. So if they quantize to the same value the one that is
the least round number gets moved the minimum distance away. For example if
we have (1, 0, 0) and (1.0000000000000001, y, z) then the second vertex
becomes (1 + delta, y, z), where delta is the lsb of the floating point
mantissa, or the grid spacing if we still need one. As long as they
maintain the same numerical order and inequalities after quantization I
think the topology might be preserved without further consideration.

On Thu, 3 Jan 2019 at 18:07, Ed Nisley ed.nisley@pobox.com wrote: