AMF export any better than STL?

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

AMF export any better than STL?

nophead
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.

image.png

I figured since they are both the same profile cut with the same surface they should match exactly, but it seems not. But OpenSCAD says the object is simple and there are two volumes. 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.

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?

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: AMF export any better than STL?

cacb
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
Reply | Threaded
Open this post in threaded view
|

Re: AMF export any better than STL?

doug.moen
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
Reply | Threaded
Open this post in threaded view
|

Re: AMF export any better than STL?

nophead
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.

On Sat, 7 Nov 2020 at 22:14, Doug Moen <[hidden email]> wrote:
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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: AMF export any better than STL?

JordanBrown
On 11/7/2020 2:26 PM, 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.

Does anybody here know what the grid units are?

It seems like it should be possible to have the grid be far smaller than any realistic feature on a model, while still being far larger than the precision of a 64-bit floating point number.  (Measuring a kilometer in micrometers is only 9 digits; 64-bit floating point is good for 15-16 digits.)


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: AMF export any better than STL?

cacb
In reply to this post by nophead
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
Reply | Threaded
Open this post in threaded view
|

Re: AMF export any better than STL?

nophead
Yes I think the grid snap causes more problems than it solves, if it solves any. There are two values both exactly representable in float. Roughly micrometers and nanometers.

//const double GRID_COARSE = 0.001;
//const double GRID_FINE = 0.000001;
/* Using decimals that are exactly convertible to binary floating point

const double GRID_COARSE = 0.0009765625;
const double GRID_FINE = 0.00000095367431640625;

You can always arrive at vertex separations much smaller than model features when you start doing CSG. For example if you have a tall thin cylinder that is tessellated with triangles and you slice a section off the end where the long thin triangles come to a point. There are lots of other examples where you can intersect two curves and get arbitrarily close vertices if you are unlucky.

Also floating point has variable resolution, so if you have small details far from the origin I think the grid points will merge when truncated to floats.

On Sat, 7 Nov 2020 at 23:19, Carsten Arnholm <[hidden email]> wrote:
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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: AMF export any better than STL?

ednisley
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
 --
Ed
softsolder.com
Reply | Threaded
Open this post in threaded view
|

Re: AMF export any better than STL?

nophead
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.

On Sun, 8 Nov 2020 at 13:25, Ed Nisley <[hidden email]> wrote:
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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
rew
Reply | Threaded
Open this post in threaded view
|

Re: AMF export any better than STL?

rew
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
Reply | Threaded
Open this post in threaded view
|

Re: AMF export any better than STL?

nophead
Yes I don't think I wouldn't notice snap to grid if it did it correctly but currently it breaks a lot of designs and when you have two curved surfaces meeting it is almost impossible guarentee to create a manifold STL.

To snap in a way that doesn't break topology is apparently very hard. 

On Sun, 8 Nov 2020 at 17:16, Rogier Wolff <[hidden email]> wrote:
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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: AMF export any better than STL?

JordanBrown
In reply to this post by nophead
[ Sent the original from the wrong address, so it probably didn't make it to the mailing list. ]

On 11/8/2020 1:48 AM, nop head wrote:
Also floating point has variable resolution, so if you have small details far from the origin I think the grid points will merge when truncated to floats.

In theory, yes, but 64-bit floating point (which is typical) has 15-16 digits of precision.

Assuming that the units are millimeters, if you have an object a kilometer from the origin you've used up 6 of those digits.  You can then accurately measure picometers with the remaining digits.

15 digits is enough to measure the distance to the Moon with sub-micrometer accuracy.

Indeed, pathological CSG cases seem like you could end up with unfortunate values, but it's a bit hard to believe that simple floating point error is a big culprit.

Now, if they go through 32-bit floating point the picture is different.  That's only measuring a kilometer to the nearest tenth of a millimeter.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: AMF export any better than STL?

cacb
In reply to this post by rew
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
Reply | Threaded
Open this post in threaded view
|

Re: AMF export any better than STL?

doug.moen
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
Reply | Threaded
Open this post in threaded view
|

Re: AMF export any better than STL?

nophead
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
Reply | Threaded
Open this post in threaded view
|

Re: AMF export any better than STL?

drxenocide
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
Reply | Threaded
Open this post in threaded view
|

Re: AMF export any better than STL?

doug.moen
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:
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
>

_______________________________________________
OpenSCAD mailing list
_______________________________________________
OpenSCAD mailing list
_______________________________________________
OpenSCAD mailing list


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: AMF export any better than STL?

nophead
3MF exported from OpenSCAD is tiny (less than 10% of an AMF) and crashes NetFabb Studio.

On Mon, 9 Nov 2020 at 14:01, Doug Moen <[hidden email]> wrote:
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:
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
>

_______________________________________________
OpenSCAD mailing list
_______________________________________________
OpenSCAD mailing list
_______________________________________________
OpenSCAD mailing list

_______________________________________________
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
tp3
Reply | Threaded
Open this post in threaded view
|

Re: AMF export any better than STL?

tp3
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
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: AMF export any better than STL?

nophead
No idea. I don't install apps on my PC, it is Win7.

On Mon, 9 Nov 2020 at 16:04, Torsten Paul <[hidden email]> wrote:
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

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