AMF export any better than STL?
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: 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?
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
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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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 doug@moens.org 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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.)
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
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 arnholm@arnholm.org 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
Discuss@lists.openscad.org
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
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 ed.nisley@pobox.com 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
Discuss@lists.openscad.org
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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
--
** R.E.Wolff@BitWizard.nl ** 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.
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 R.E.Wolff@bitwizard.nl 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
--
** R.E.Wolff@BitWizard.nl ** 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
[ 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.
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
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
Discuss@lists.openscad.org
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 doug@moens.org 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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 nop.head@gmail.com 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 doug@moens.org 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
Discuss@lists.openscad.org
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 nop.head@gmail.com 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 doug@moens.org 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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 doug@moens.org 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 nop.head@gmail.com 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 doug@moens.org 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
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.
No idea. I don't install apps on my PC, it is Win7.
On Mon, 9 Nov 2020 at 16:04, Torsten Paul Torsten.Paul@gmx.de 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org