AMF export any better than STL?

The "simple" designation comes from CGAL (got that from reading the source). CGAL generates meshes that are free from self intersection, but the coordinates are represented as infinite precision rational numbers. The process of converting a defect free CGAL mesh to any of the mesh file formats includes: converting the rational numbers to floating point, which perturbs the coordinate values and can introduce self intersections. The conversion process apparently also includes "snapping to a grid" (learned that from forum posts), which can also introduce self intersections. So I think that if CGAL says the mesh is simple, then that does not preclude the exported mesh from containing self intersections.

On Sat, Nov 7, 2020, at 4:54 PM, Carsten Arnholm wrote:
> On 07.11.2020 22:29, nop head wrote:
> > I have a design with some questionable bits in it where I cut a section
> > out of a ring with a shape that overlaps it and then unions another
> > shape that is intersected with the same overlapping shape to exactly
> > fill the gap. Normally I would overlap them but I can't see a way how to
> > in this case because it is part of a curve. If I extend along the curve
> > I expect the sides will be nearly coincident but not.
>
> The above does not make any sense to me/not possible to understand.
> Maybe you have a code snippet for this? or the AMF/STL?
>
> > When I export to STL NetFabb
> > tells me there are self intersections at the joins, so I tried AMF
> > export but that still gives the same self intersections. It also takes
> > forever to export and produces a big file.
>
> AMF takes up more space since it is XML. How long it takes to export
> depends on implementation. OFF and OBJ formats are more efficient
> (OpenSCAD can export OFF).
>
> Both AMF, OBJ and OFF are better than STL since they include exact
> topology and do not require any coordinate matching as STL does.
> However, if the model is originally self intersecting, using either
> format will not make any difference.
>
> > So when OpenSCAD says the object is simple does that guarantee it is
> > manifold without self intersections? If so, why is it still broken in AMF?
>
> I don't know what "simple" means in this context either. Does OpenSCAD
> detect all self-intersections? If it does not, the file format will not
> fix it.
>
> Carsten Arnholm
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

On 07.11.2020 23:26, nop head wrote:
> Yes it looks like the grid snap breaks it before it gets exported, so it
> doesn't make any difference how it is exported. I.e. naively assumed AMF
> would preserve the topology from CGAL.

There is no reason to apply "grid snap". In particular, if you export to
a format like AMF, OBJ or OFF, each vertex is represented exactly once
anyway so it makes no sense and can only cause problems.

Carsten Arnholm

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

On 11/8/20 4:48 AM, nop head wrote:
> if it solves any

I may be partially responsible for the current state of affairs:

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

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

Six years (!) on, perhaps slicers can auto-fix imperfect models with
better results and non-gridded coordinates would work or, at least, not
fail quite so spectacularly.

But, yuch, everything is deeply intertwingled!

--
Ed
https://softsolder.com

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

On Sun, Nov 08, 2020 at 01:36:31PM +0000, nop head wrote:
> Anywhere in OpenSCAD that reduces the vertex resolution has the potential
> to break things. For example rationals to double, double to float and
> possibly 64bit fixed point (used in the 2D subsystem) to double. The only
> solution is an intelligent snap that preserves topology wherever vertices
> are truncated or a mesh fixup step afterwards that would also fix broken
> STLs that produce 90% of the questions and bug reports.

I understand the need for this snap-to-grid behaviour: A point that is
calculated as rotated 45 degrees and a point that is calculated as 9
rotationss of 5 degrees usually end up pretty close and for STLs it
would be nice if they end up being really the same point instead of
adding microscopic extra triangles.

I've probably said this before: I would favor a snap-to-grid setting
that is configurable by the user. If you're modelling a death star,
the grid might be 1mm or 1cm, but when you're making models for your
atomic-scale-3D-printer, 1nm (about 10 atoms) is way too much!

        Roger.

> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


--
** [hidden email] ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

According to <https://github.com/openscad/openscad/pull/1115>,
what "snap-to-grid" does is "Quantize vertices when building Nef polyhedrons from PolySets".

So the "quantization" or "snap-to-grid" behaviour is applied before the mesh is given to CGAL. If quantization is creating self intersections, then it would be causing CGAL errors. Quantization cannot create self intersections in a mesh file export, because it is only used for creating inputs to CGAL operations (union, intersection, difference, maybe some others). And, the output of a CGAL operation is a Nef polyhedron, which cannot contain self intersections (not before it is converted to floating point).

Ed Nisley's bug report suggests that quantization does eliminate self intersection in some cases. The only way I see that happening is if the input to CGAL contains valid geometry that is "close to the edge" of being self intersecting, and when the CGAL output is converted to floating point, that "close to the edge" property of the geometry is enough that the slight vertex perturbation caused by conversion to floating point is enough to create self intersections. So in this case, the quantization happens to make the models in question more robust against vertex perturbation.

I think that whether quantization helps or hurts is model dependent. Quantization could avoid self intersection in the mesh export, but it could also introduce self intersection in the CGAL input and cause CGAL errors. User control of snap-to-grid behaviour would be useful, and since it is model dependent, it should be a $ variable instead of a config setting.

Doug Moen.

On Sun, Nov 8, 2020, at 9:14 PM, Carsten Arnholm wrote:
> On 08.11.2020 18:15, Rogier Wolff wrote:
> > I understand the need for this snap-to-grid behaviour: A point that is
> > calculated as rotated 45 degrees and a point that is calculated as 9
> > rotationss of 5 degrees usually end up pretty close and for STLs it
> > would be nice if they end up being really the same point instead of
> > adding microscopic extra triangles.
>
> Storing to STL does not create extra triangles. Storing to any format
> does not create extra triangles. If you get extra triangles, it happens
> in the boolean engine (CGAL in OpenSCADs case).
>
> Carsten Arnholm
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

The quantization more often than not breaks things and gives CGAL errors if quantizing the points ever makes two collapse. If they are all further apart than the grid resolution it just perterbs them slightly but if any merge then things break. If they don't merge then aligning on a grid helps to make edges precisely align and avoid tiny triangles but probably has a 50% chance of doing the opposite.

If all three points of a triangle merge it removes the whole triangle and that is the only case that works. If two are close then you get a degenerate triangle, which CGAL does not like. I made a PR that fixed the degenerate triangles with edge flips and that worked fine but if you have something tapering to a point it can collapse two surfaces together and that makes a self intersection. Also the snap of points of a long thin triangle can reverse its winding order and that also upsets CGAL and is probably reported as self intersection in NetFabb.

If it isn't used in export then it must be rational to double and double to float truncations that have exactly the same problem. Every time it converts from Nef to PolySet it throws away the topology and makes a polygon soup. In my case the end result was from CGAL but in other cases it could be PolySet, so the AMF export would have no topology to work with.

My result also had holes and lots of degenerate triangles but those are easy to fix with NetFabb. Perhaps I will have to buy the version that fixes self intersections if OpenSCAD doesn't fix this. It has been a constant problem from day one. I can normally work around it when I make engineering parts but it is virtually impossible with this aesthetic part. It is a stage prop but the director has changed his mind about what it should look like, so the next version might be OK, who knows?

On Mon, 9 Nov 2020 at 01:03, Doug Moen <[hidden email]> wrote:

According to <https://github.com/openscad/openscad/pull/1115>,
what "snap-to-grid" does is "Quantize vertices when building Nef polyhedrons from PolySets".

So the "quantization" or "snap-to-grid" behaviour is applied before the mesh is given to CGAL. If quantization is creating self intersections, then it would be causing CGAL errors. Quantization cannot create self intersections in a mesh file export, because it is only used for creating inputs to CGAL operations (union, intersection, difference, maybe some others). And, the output of a CGAL operation is a Nef polyhedron, which cannot contain self intersections (not before it is converted to floating point).

Ed Nisley's bug report suggests that quantization does eliminate self intersection in some cases. The only way I see that happening is if the input to CGAL contains valid geometry that is "close to the edge" of being self intersecting, and when the CGAL output is converted to floating point, that "close to the edge" property of the geometry is enough that the slight vertex perturbation caused by conversion to floating point is enough to create self intersections. So in this case, the quantization happens to make the models in question more robust against vertex perturbation.

I think that whether quantization helps or hurts is model dependent. Quantization could avoid self intersection in the mesh export, but it could also introduce self intersection in the CGAL input and cause CGAL errors. User control of snap-to-grid behaviour would be useful, and since it is model dependent, it should be a $ variable instead of a config setting.

Doug Moen.

On Sun, Nov 8, 2020, at 9:14 PM, Carsten Arnholm wrote:
> On 08.11.2020 18:15, Rogier Wolff wrote:
> > I understand the need for this snap-to-grid behaviour: A point that is
> > calculated as rotated 45 degrees and a point that is calculated as 9
> > rotationss of 5 degrees usually end up pretty close and for STLs it
> > would be nice if they end up being really the same point instead of
> > adding microscopic extra triangles.
>
> Storing to STL does not create extra triangles. Storing to any format
> does not create extra triangles. If you get extra triangles, it happens
> in the boolean engine (CGAL in OpenSCADs case).
>
> Carsten Arnholm
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

3MF is an improved version of AMF.

3MF discourages producers from generating self intersecting meshes, but because it's so hard for generalized mesh generators to completely avoid self intersections, it isn't prohibited, unlike AMF. 3MF encourages consumers to accept self intersecting meshes, and provides an algorithm for unambiguously interpreting self intersecting meshes, unlike AMF. So a self intersecting 3MF file generated by OpenSCAD should print the same in all slicer programs, otherwise it is a bug in the slicer.

So while AMF isn't any better than STL for self intersecting models, 3MF *is* better.

3MF is an open standard, freely available on the internet, while AMF is pay per read; it can't legally be shared over the web, so each open source developer is supposed to purchase their own copy. This helps explain why some open source projects have dropped AMF support (who wants to maintain the code?) There's little interest today in adding new AMF support. AMF is a dying standard.

On Mon, Nov 9, 2020, at 8:13 AM, Ari Diacou wrote:

Since no one has mentioned it yet: AMF is nice in that preserves different objects, and i think color information? 3MF definitely has color information. I use AMF when I want to generate multiple objects, and dont want to bother with "seperate connected surfaces" before arranging them on the buildplate in the slicer.

On Mon, Nov 9, 2020 at 2:40 AM nop head <[hidden email]> wrote:

The quantization more often than not breaks things and gives CGAL errors if quantizing the points ever makes two collapse. If they are all further apart than the grid resolution it just perterbs them slightly but if any merge then things break. If they don't merge then aligning on a grid helps to make edges precisely align and avoid tiny triangles but probably has a 50% chance of doing the opposite.

If all three points of a triangle merge it removes the whole triangle and that is the only case that works. If two are close then you get a degenerate triangle, which CGAL does not like. I made a PR that fixed the degenerate triangles with edge flips and that worked fine but if you have something tapering to a point it can collapse two surfaces together and that makes a self intersection. Also the snap of points of a long thin triangle can reverse its winding order and that also upsets CGAL and is probably reported as self intersection in NetFabb.

If it isn't used in export then it must be rational to double and double to float truncations that have exactly the same problem. Every time it converts from Nef to PolySet it throws away the topology and makes a polygon soup. In my case the end result was from CGAL but in other cases it could be PolySet, so the AMF export would have no topology to work with.

My result also had holes and lots of degenerate triangles but those are easy to fix with NetFabb. Perhaps I will have to buy the version that fixes self intersections if OpenSCAD doesn't fix this. It has been a constant problem from day one. I can normally work around it when I make engineering parts but it is virtually impossible with this aesthetic part. It is a stage prop but the director has changed his mind about what it should look like, so the next version might be OK, who knows?

On Mon, 9 Nov 2020 at 01:03, Doug Moen <[hidden email]> wrote:

According to <https://github.com/openscad/openscad/pull/1115>,

what "snap-to-grid" does is "Quantize vertices when building Nef polyhedrons from PolySets".

So the "quantization" or "snap-to-grid" behaviour is applied before the mesh is given to CGAL. If quantization is creating self intersections, then it would be causing CGAL errors. Quantization cannot create self intersections in a mesh file export, because it is only used for creating inputs to CGAL operations (union, intersection, difference, maybe some others). And, the output of a CGAL operation is a Nef polyhedron, which cannot contain self intersections (not before it is converted to floating point).

Ed Nisley's bug report suggests that quantization does eliminate self intersection in some cases. The only way I see that happening is if the input to CGAL contains valid geometry that is "close to the edge" of being self intersecting, and when the CGAL output is converted to floating point, that "close to the edge" property of the geometry is enough that the slight vertex perturbation caused by conversion to floating point is enough to create self intersections. So in this case, the quantization happens to make the models in question more robust against vertex perturbation.

I think that whether quantization helps or hurts is model dependent. Quantization could avoid self intersection in the mesh export, but it could also introduce self intersection in the CGAL input and cause CGAL errors. User control of snap-to-grid behaviour would be useful, and since it is model dependent, it should be a $ variable instead of a config setting.

Doug Moen.

On Sun, Nov 8, 2020, at 9:14 PM, Carsten Arnholm wrote:

> On 08.11.2020 18:15, Rogier Wolff wrote:

> > I understand the need for this snap-to-grid behaviour: A point that is

> > calculated as rotated 45 degrees and a point that is calculated as 9

> > rotationss of 5 degrees usually end up pretty close and for STLs it

> > would be nice if they end up being really the same point instead of

> > adding microscopic extra triangles.

>

> Storing to STL does not create extra triangles. Storing to any format

> does not create extra triangles. If you get extra triangles, it happens

> in the boolean engine (CGAL in OpenSCADs case).

>

> Carsten Arnholm

>

> _______________________________________________

> OpenSCAD mailing list

> [hidden email]

> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

>

_______________________________________________

OpenSCAD mailing list

[hidden email]

http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________

OpenSCAD mailing list

[hidden email]

http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________

OpenSCAD mailing list

[hidden email]

http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

On 09.11.20 16:56, nop head wrote:
> 3MF exported from OpenSCAD is tiny (less than 10% of an AMF) and
> crashes NetFabb Studio.

I suspect the size difference is mostly due to OpenSCAD only
exporting AMF as XML, not zipped. The spec supports ZIP archives
too.
Content wise both are XML, so they are probably not that much
different when using the limited feature set OpenSCAD implements.

Not sure why it would crash NetFabb, does it load in 3D Builder?

ciao,
  Torsten.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org