AMF export any better than STL?
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