stl, amf, off, 3mf

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

stl, amf, off, 3mf

Parkinbot
I am currently preparing an update to my thingiverse post  globoid worm gear
<https://www.thingiverse.com/thing:2776688>   where I show the simulation of
a  subtractive process
<https://cdn.thingiverse.com/assets/8b/4e/87/f7/3d/story.gif>   in order to
create a worm-gear couple. In contrast to the referred post I now construct
the worm (and the cutting tool) in a direct fashion by sweeping an explicit
2D spline, which avoids the first difference operation. This speeds up the
whole process and leads to a more stable and reliable output.

However, even CGAL succeeds to render proper objects which I can export into
stl format, a proper reimport of such an STL is not possible in most cases,
in the sense that a union with a cube(1) leads to a CGAL error. Therefore I
started to experiment with the other available file formats and found out
that the problem also exists with AMF and OFF, but *not with 3MF*.
Therefore I suspected that it is the number of digits in the vertex
coordinates that differs and leads to the problem. To check this, I exported

rotate(5) cube(100);

into all four formats and checked the representation of the same coordinate.
Here the results:

STL
    vertex 90.9039 108.335 100

OFF
    90.9039 108.335 100

AMF
    <vertex><coordinates>
     <x>90.9039</x>
     <y>108.335</y>
     <z>100</z>

3MF (to view: rename file.3mf to file.zip and unzip the text file
3dmodel.model)
   <vertex x="90.903896" y="108.335048" z="100.000000" />

3mf obviously contains output more digits and more close to the exact
representation used by OpenSCAD. But due to binary/decimal conversion issues
it also might have its limits.

1. While binary formats seem to be limited to single (16 bit) values I don't
know whether at least the text formats for STL, AMF and OFF, forbid it to
output more digits. But wouldn't it be a solution to do so? I suspect, that
most - if not all - importers don't care anyway.

2. Wouldn't it make sense to introduce/offer an output format that *exactly*
represents an OpenSCAD object and can thus be imported without any losses
and risks. I personally wouldn't mind if such a format was proprietary,
because one can always use OpenSCAD as converter.








--
Sent from: http://forum.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: stl, amf, off, 3mf

Tim V. Shaporev
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.

On 3/2/2020 6:22 PM, Parkinbot wrote:

> I am currently preparing an update to my thingiverse post  globoid worm gear
> <https://www.thingiverse.com/thing:2776688>   where I show the simulation of
> a  subtractive process
> <https://cdn.thingiverse.com/assets/8b/4e/87/f7/3d/story.gif>   in order to
> create a worm-gear couple. In contrast to the referred post I now construct
> the worm (and the cutting tool) in a direct fashion by sweeping an explicit
> 2D spline, which avoids the first difference operation. This speeds up the
> whole process and leads to a more stable and reliable output.
>
> However, even CGAL succeeds to render proper objects which I can export into
> stl format, a proper reimport of such an STL is not possible in most cases,
> in the sense that a union with a cube(1) leads to a CGAL error. Therefore I
> started to experiment with the other available file formats and found out
> that the problem also exists with AMF and OFF, but *not with 3MF*.
> Therefore I suspected that it is the number of digits in the vertex
> coordinates that differs and leads to the problem. To check this, I exported
>
> rotate(5) cube(100);
>
> into all four formats and checked the representation of the same coordinate.
> Here the results:
>
> STL
>      vertex 90.9039 108.335 100
>
> OFF
>      90.9039 108.335 100
>
> AMF
>      <vertex><coordinates>
>       <x>90.9039</x>
>       <y>108.335</y>
>       <z>100</z>
>
> 3MF (to view: rename file.3mf to file.zip and unzip the text file
> 3dmodel.model)
>     <vertex x="90.903896" y="108.335048" z="100.000000" />
>
> 3mf obviously contains output more digits and more close to the exact
> representation used by OpenSCAD. But due to binary/decimal conversion issues
> it also might have its limits.
>
> 1. While binary formats seem to be limited to single (16 bit) values I don't
> know whether at least the text formats for STL, AMF and OFF, forbid it to
> output more digits. But wouldn't it be a solution to do so? I suspect, that
> most - if not all - importers don't care anyway.
>
> 2. Wouldn't it make sense to introduce/offer an output format that *exactly*
> represents an OpenSCAD object and can thus be imported without any losses
> and risks. I personally wouldn't mind if such a format was proprietary,
> because one can always use OpenSCAD as converter.
>
>
>
>
>
>
>
>
> --
> Sent from: http://forum.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: stl, amf, off, 3mf

cacb
In reply to this post by Parkinbot
On 2020-03-02 16:22, Parkinbot wrote:
> 3mf obviously contains output more digits and more close to the exact
> representation used by OpenSCAD. But due to binary/decimal conversion
> issues
> it also might have its limits.

The numeric precision of the ascii file formats (STL, AMF, OFF and
probably 3MF)is a property of the software that wrote those files , not
a property of the file formats themselves. For example, xcsg (
https://github.com/arnholm/xcsg ) writes ASCII versions of those files
in up to 12 digit precision (where required).

> 1. While binary formats seem to be limited to single (16 bit) values I
> don't
> know whether at least the text formats for STL, AMF and OFF, forbid it
> to
> output more digits. But wouldn't it be a solution to do so? I suspect,
> that
> most - if not all - importers don't care anyway.

This is not correct. Binary STL contains 32bit floating point
coordinates, i.e. single precision. OFF is ASCII only I think, there is
no limit to the numeric precision you can write to it, but there is no
point in writing higher precision than the precision of the software
reading those files.

> 2. Wouldn't it make sense to introduce/offer an output format that
> *exactly*
> represents an OpenSCAD object and can thus be imported without any
> losses
> and risks. I personally wouldn't mind if such a format was proprietary,
> because one can always use OpenSCAD as converter.

A good start would be for OpenSCAD to write binary STL by default, that
would give you 32 bit precision right away, smaller files and faster
reads.

On the other hand, one should not really use STL for anything, as it is
just a polygon soup in all cases. Better to use e.g. OFF with 12 digit
precision.

That being said, there is nothing to stop you from writing formatted
files with c (64 bit) , for STL, AMF or OFF, but the importer must use
double precision as well.

Now, if you want *exactly* what OpenSCAD uses internally (in CGAL), I
suspect things will be getting really ugly. xcsg uses standard 64 bit
double precision internally, but CGAL uses its peculiar numeric
representation (causing slowness).

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: stl, amf, off, 3mf

cacb
In reply to this post by Parkinbot
On 02.03.2020 16:22, Parkinbot wrote:

> To check this, I exported
>
> rotate(5) cube(100);
>
> into all four formats and checked the representation of the same coordinate.
> Here the results:
>
> STL
>      vertex 90.9039 108.335 100
>
> OFF
>      90.9039 108.335 100
>
> AMF
>      <vertex><coordinates>
>       <x>90.9039</x>
>       <y>108.335</y>
>       <z>100</z>
>
> 3MF (to view: rename file.3mf to file.zip and unzip the text file
> 3dmodel.model)
>     <vertex x="90.903896" y="108.335048" z="100.000000" />

I repeated that example using xcsg

Formatted STL (binary STL is preferred in xcsg)

      vertex 90.90389553440875 108.3350440839404 100

OFF
      90.9038955344 108.335044084 100

AMF
     <coordinates>
          <x>90.903895534408747</x>
          <y>108.33504408394037</y>
          <z>100</z>
     </coordinates>


OBJ
     v 90.9038955344 108.335044084 100


There is a slight mismatch in the number of digits that xcsg generates
for these formats, they should really all be the same, and at some stage
it is just "numeric noise". But your examples have clearly truncated the
numbers to become useless for import.

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: stl, amf, off, 3mf

Parkinbot
In reply to this post by cacb
> 1. While binary formats seem to be limited to single (16 bit) values I

Carsten, you are half right. It is 32 bit that is used for *single*
precision. I don't know, why I wrote 16 bit, sorry for this. Of course any
modern CAD program will internally use double values (64bit) as CPUs
natively support them. This means that values in binary STLs also truncated.
As we know from several elder threads OpenSCAD internally uses several
representations from single to double to fixed point and as CGAL is
concerned rationals.

However I think we could gain a lot, if we were able to persist OpenSCAD
objects in a lossless format.




--
Sent from: http://forum.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: stl, amf, off, 3mf

frankv
In reply to this post by cacb
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.


On Tue, Mar 3, 2020 at 5:15 AM Carsten Arnholm <[hidden email]> wrote:
On 02.03.2020 16:22, Parkinbot wrote:
> To check this, I exported
>
> rotate(5) cube(100);
>
> into all four formats and checked the representation of the same coordinate.
> Here the results:
>
> STL
>      vertex 90.9039 108.335 100
>
> OFF
>      90.9039 108.335 100
>
> AMF
>      <vertex><coordinates>
>       <x>90.9039</x>
>       <y>108.335</y>
>       <z>100</z>
>
> 3MF (to view: rename file.3mf to file.zip and unzip the text file
> 3dmodel.model)
>     <vertex x="90.903896" y="108.335048" z="100.000000" />

I repeated that example using xcsg

Formatted STL (binary STL is preferred in xcsg)

      vertex 90.90389553440875 108.3350440839404 100

OFF
      90.9038955344 108.335044084 100

AMF
     <coordinates>
          <x>90.903895534408747</x>
          <y>108.33504408394037</y>
          <z>100</z>
     </coordinates>


OBJ
     v 90.9038955344 108.335044084 100


There is a slight mismatch in the number of digits that xcsg generates
for these formats, they should really all be the same, and at some stage
it is just "numeric noise". But your examples have clearly truncated the
numbers to become useless for import.

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: stl, amf, off, 3mf

cacb
In reply to this post by Parkinbot
On 2020-03-02 18:20, Parkinbot wrote:
>> 1. While binary formats seem to be limited to single (16 bit) values I
>
> Carsten, you are half right. It is 32 bit that is used for *single*
> precision.

That's what I said.

> I don't know, why I wrote 16 bit, sorry for this. Of course any
> modern CAD program will internally use double values (64bit) as CPUs
> natively support them. This means that values in binary STLs also
> truncated.

It depends. 32 bit floating point numbers correspond to approximately 7
decimal digits. 64 bit floating point numbers correspond to
approximately 16 decimal digits. 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.

> As we know from several elder threads OpenSCAD internally uses several
> representations from single to double to fixed point and as CGAL is
> concerned rationals.  hard.

And this means that single precision on binary STL will be good enough
until you got those other issues sorted.

> However I think we could gain a lot, if we were able to persist
> OpenSCAD
> objects in a lossless format.

I would challenge you to define lossless in this context, it is harder
than it may seem. Defining a binary format with 64 bit double precision
is the easy part. An as mentioned before, the existing formats support
double precision already, so why not use them?

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: stl, amf, off, 3mf

cacb
In reply to this post by frankv
On 2020-03-02 18:24, 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.

This is correct only for the final step in the process (assuming the
process is 3d printing, sometimes it is not).

Parkinbots starting premise was that he wanted to import an existing
model (in STL, OFF or whatever) and further process it. In such a
situation it is essential that all precision is retained. Importing
models with truncated precision is almost always guaranteed major
problems.

Not understanding this has caused a lot of problems for people.

Cartsten Arnhol,

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

Re: stl, amf, off, 3mf

Alan Cox-2
In reply to this post by Parkinbot
On Mon, 2 Mar 2020 10:20:15 -0700 (MST)
Parkinbot <[hidden email]> wrote:

> > 1. While binary formats seem to be limited to single (16 bit) values I  
>
> Carsten, you are half right. It is 32 bit that is used for *single*
> precision. I don't know, why I wrote 16 bit, sorry for this. Of course any
> modern CAD program will internally use double values (64bit) as CPUs
> natively support them. This means that values in binary STLs also truncated.
> As we know from several elder threads OpenSCAD internally uses several
> representations from single to double to fixed point and as CGAL is
> concerned rationals.
>
> However I think we could gain a lot, if we were able to persist OpenSCAD
> objects in a lossless format.

Or at least a stable one. Part of the problem with things like STL is
that if you blindly write or read floats you get ambiguity between points
and OpenSCAD doesn't use a point dictionary to resolve it.

Personally I'd use 64bit 32.32 fixed precision if I was writing these
kinds of tools. Whilst PC class hardware is pretty fast at floats a lot
of tablet/phone devices are not.

32.32 fixed point for the usual 1 = 1mm covers a range of +/- 4294
kilometres at a precision sufficient for everyone (even people assembling
molecules) *and* the accuracy of your object doesn't depend on its
distance from the 0. With floats if you translate an object away from the
centre it gets less accurate and can change, as well as the fact that
translating an object somewhere away from the centre and back loses
accuracy in most unintuitive ways.

Alan

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

Re: stl, amf, off, 3mf

Alan Cox-2
In reply to this post by Tim V. Shaporev
On Mon, 2 Mar 2020 18:50:43 +0300
"Tim V. Shaporev" <[hidden email]> 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

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

Re: stl, amf, off, 3mf

Parkinbot
In reply to this post by cacb
>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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: stl, amf, off, 3mf

nophead
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 <[hidden email]> 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
[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: stl, amf, off, 3mf

MichaelAtOz
Administrator
> 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/

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

Re: stl, amf, off, 3mf

rew
In reply to this post by frankv
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.


--
** [hidden email] ** 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: stl, amf, off, 3mf

nophead
> 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 <[hidden email]> 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.


--
** [hidden email] ** 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
[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: stl, amf, off, 3mf

Tim V. Shaporev
In reply to this post by Alan Cox-2
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" <[hidden email]> 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
>

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

Re: stl, amf, off, 3mf

Alan Cox-2
In reply to this post by rew
> 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

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