stl, amf, off, 3mf
I will standardise on 16 decimal digits
for formatted output of coordinates, but it is really overkill since the
last few digits are mostly noise.
The "noise" depends on the operations that produce a result and not on the
representation. You can argue the same for a 5 digit format and drop the
last 4 digits.
But let's be constructive: OpenSCAD has a cache mechanism. This means there
is a CGAL compliant object format which could be used to persist a cached
object. And there is place - the cache - where it can be imported again.
Having such a format, the "standardized" output formats STL, AMF, OFF, 3MF
could indeed be used for for printing objects and not imperative also for
reimport.
--
Sent from: http://forum.openscad.org/
If there are two
points that would collide because of precision loss then you jiggle them
by the smallest possible value up or down (and repeating if need be) so
that the points remain unambiguous and correctly numerically ordered (and
the error introduced is microscopic in proportion the value).
I think it is very difficult to guarantee almost degenerate triangles don't
flip winding order or very geometrically close but topologically distant
surfaces don't intersect if you do that.
On Mon, 2 Mar 2020 at 18:16, Parkinbot rudolf@digitaldocument.de wrote:
I will standardise on 16 decimal digits
for formatted output of coordinates, but it is really overkill since the
last few digits are mostly noise.
The "noise" depends on the operations that produce a result and not on the
representation. You can argue the same for a 5 digit format and drop the
last 4 digits.
But let's be constructive: OpenSCAD has a cache mechanism. This means there
is a CGAL compliant object format which could be used to persist a cached
object. And there is place - the cache - where it can be imported again.
Having such a format, the "standardized" output formats STL, AMF, OFF, 3MF
could indeed be used for for printing objects and not imperative also for
reimport.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
If there are two
points that would collide because of precision loss then you jiggle them
by the smallest possible value up or down (and repeating if need be) so
that the points remain unambiguous and correctly numerically ordered (and
the error introduced is microscopic in proportion the value).
3MF actually calls for such points to be collapsed
The vertices element contains all the
<vertex>
elements for this object. The vertices represent the corners of each
triangle in the mesh. The order of these elements defines an implicit
0-based index that is referenced by other elements, such as the
<triangle>
element. The producer SHOULD NOT include duplicate vertices unless
coalescing duplicates would create non-manifold edges. Furthermore, a
producer SHOULD collapse vertices that are very closely proximal with a
single vertex whenever appropriate. In order to avoid integer overflows, a
vertex array MUST contain less than 2^31 vertices.
A
<vertex>
element represents a point in 3-dimensional space that is referenced by a
triangle in the mesh. The decimal values representing the coordinates can
be recorded to arbitrary precision. Producers SHOULD NOT use more
precision than the error generated in their calculations, or the
anticipated resolution of their consumer. The variable-precision nature of
ASCII encoding is a significant advantage over fixed-width binary formats,
and helps make up the difference in storage efficiency.
The use of a vertex table helps.
I actually think the OpenSCAD 'grid' code* is actually trying to do that,
and I suspect a gremlin in there.
*
https://github.com/openscad/openscad/blob/c6a485651fa29f1a878ea454558192492f7467ec/src/grid.h
I tried following the code, but needed debug info & don't have a dev
environment.
I'm also wondering if the grid size,
const double GRID_COARSE = 0.0009765625;
const double GRID_FINE = 0.00000095367431640625;
is too fine in relation to the precision of the various output formats.
Admin - email* me if you need anything, or if I've done something stupid...
- click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
--
Sent from: http://forum.openscad.org/
On Tue, Mar 03, 2020 at 06:24:00AM +1300, Frank van der Hulst wrote:
3D-printing precision is normally about 80 steps/mm or so. Of course, you
can build a printer with higher (or lower) precision, but I doubt that
accuracy of all the mechanisms could be much better than +/-.001mm. So
specifying points to precision better than .001mm would usually be
pointless.
Of course, sometimes you have to make asumptions and optimizations
that depend on what you think stuff will be used for.
Such an artificial limit: "Objects are usually not smaller than 10
microns" is a weird artificial limit that should be avoided if at all
possible.
A limit like: Accuracy is a factor of a million: we calculate the
largest size of the model at hand and 1 million smaller than that is
the unit/grid. This will still create funny (not!) artefacts in that
some objects might behave differently depending on their surrounding,
but at least you can make objects that are built from individual
atoms(*).
Roger.
(*) Note that IBM manipulated individual atoms in a plane over 30
years ago to spell IBM. One of these days someone is going to be
making 3D structures using individual atoms.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
3MF actually calls for such points to be collapsed
OpenSCAD does that but it breaks because it does it to PolySet objects
which are just a polygon soup, like an STL, but polygons instead of just
triangles and doubles instead of floats.
If you have something tapering to a sharp point then collapsing the
vertices can cause two separate surfaces to meet and make self
intersections. Presumably 3MF gets away with it because it also stores the
topology, so the two surfaces would remain topologically distinct despite
overlapping geometrically, You would get a negative volume that could be
removed to leave a hole in the object instead if being microscopically thin.
On Tue, 3 Mar 2020 at 07:59, Rogier Wolff R.E.Wolff@bitwizard.nl wrote:
On Tue, Mar 03, 2020 at 06:24:00AM +1300, Frank van der Hulst wrote:
3D-printing precision is normally about 80 steps/mm or so. Of course, you
can build a printer with higher (or lower) precision, but I doubt that
accuracy of all the mechanisms could be much better than +/-.001mm. So
specifying points to precision better than .001mm would usually be
pointless.
Of course, sometimes you have to make asumptions and optimizations
that depend on what you think stuff will be used for.
Such an artificial limit: "Objects are usually not smaller than 10
microns" is a weird artificial limit that should be avoided if at all
possible.
A limit like: Accuracy is a factor of a million: we calculate the
largest size of the model at hand and 1 million smaller than that is
the unit/grid. This will still create funny (not!) artefacts in that
some objects might behave differently depending on their surrounding,
but at least you can make objects that are built from individual
atoms(*).
Roger.
(*) Note that IBM manipulated individual atoms in a plane over 30
years ago to spell IBM. One of these days someone is going to be
making 3D structures using individual atoms.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110
**
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
You are right, but implementation of such a general case solution is
more ambitious task than increasing number of digits on output. :-)
On 3/2/2020 9:14 PM, Alan Cox wrote:
On Mon, 2 Mar 2020 18:50:43 +0300
"Tim V. Shaporev" tim.shaporev@auriga.ru wrote:
Do you mean 32-bit (not 16) binary IEEE floating-point format?
As far as I read it requires up to 9 decimal digits to represent its
value as a text so the current dumper implementation involves accuracy
loss against binary STL either.
I see no good reason to hold on 6 meaningful digits output.
What matters is not just the digits but the fact that you don't end up
with two different points having the same value. Ditto any 'noise' needs
to cause points to collide of swap over when exported/imported.
A good STL exporter creates a list of every point. If there are two
points that would collide because of precision loss then you jiggle them
by the smallest possible value up or down (and repeating if need be) so
that the points remain unambiguous and correctly numerically ordered (and
the error introduced is microscopic in proportion the value).
Alan
Such an artificial limit: "Objects are usually not smaller than 10
microns" is a weird artificial limit that should be avoided if at all
possible.
Why ? If you are using something stable like 32:32 fixed point then you
are not going to be building an object that is 4000Km across and detailed
in the nanometers range, and openscad is unscaled. If you want to build
the solar system at the atomic level use 64:64 - still faster than a
double on smaller processors.
A limit like: Accuracy is a factor of a million: we calculate the
largest size of the model at hand and 1 million smaller than that is
the unit/grid. This will still create funny (not!) artefacts in that
some objects might behave differently depending on their surrounding,
but at least you can make objects that are built from individual
atoms(*).
This is sort of what happens now, except that accuracy is a factor of
size and distance from 0,0,0 in STL.
Alan