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.