It is an analogue world. Thus, the best you can do digitally is use lots
of discrete points to represent curved things. Imagination and guesswork
plays a large part in transferring between dimensions. It's a bit of a
miracle that we can understand any of this.

The advantage of an stl file is that  it is generally a collection of
groups of three points, representing the corner of triangles.

The disadvantage of an stl file can be that it is merely a collection of
groups of three points representing the corner of triangles.

There is no requirement in the file to ensure that vertexes align, etc.,
or the object is water tight. For example, you can import a couple of
triangles into openscad (and elsewhere) as a valid stl file. It will be
handled as a 3d object with f5 render, it will disappear as an f6, but
you can move it around and export is as an stl, even if you can't see
it, but if exported, it will show in meshlab, maybe others, but not in
cura, say. (I wouldn't expect cura to handle planes, it needs
'thickness') I think this may be something that could be exploited.

On 02/09/2022 20:42, andrew goh via Discuss wrote:

On 02/09/2022 21:22, Raymond West wrote:

Sorry if you wasted time trying out the above, I got a bit mixed up
there, with all my recent playing about with broken stl's. However, if
you export a cube as an stl, and then delete the two sets of vertexes
representing the bottom face (probably just delete any one vertex set
would do), say, and import it into openscad as an stl, it 'looks like' a
hollow cube'  if you f5 or f6 it. However if you then create another
proper 3d object (another cube, say) then f5 will show both, but f6 does
not show the corrupted cube, but both are exported as an stl.

You can get 'interesting results' if you difference/union/intersection
cube and the cottupted cube'.

On 9/2/2022 1:22 PM, Raymond West wrote:

Not at all true.

You can represent curves mathematically, and then they aren't dependent
on discrete points.

It sounds like SVG has Béziers as a native mechanism, which means that
an SVG file can have infinite-precision curves.

Yes, when you render a curve onto a display it has to be rendered as
pixels, but you can zoom in infinitely and you will never see distinct
points.

An Inkscape ellipse (which is also an SVG ellipse), is a mathematical
circle and has infinite precision.  Until you reach the boundaries of
floating point precision, you can enlarge it without seeing discrete
points.  And even then, that's only a limitation of the floating point
math that the program is using; if it used higher-precision floating
point you could zoom in further.

OpenSCAD makes its curve-to-line conversion visible, and that's kind of
unfortunate.  Better would be if circle() produced a mathematical circle
that only turned into distinct points and segments at a lower layer, if
at all.  However, that would make the geometry processing that OpenSCAD
does (e.g. union, difference, and the triangularization that the
previewer does) much harder.

On 02/09/2022 23:16, Jordan Brown wrote:

Thus, the best you can do digitally is use lots of discrete points to
represent curved things. I was referring to digital representation of
the analogue world, not a mathematical representation. But, even so, If
you draw something with perfect smooth curves in theory, whatever you do
with that, either view it on a vdu, or try and machine it/whatever,
drill down fine enough and you will come to steps in the surface, or
something else that does not match the mathematical shape, due to the
limits of the material, measuring equipment/whatever. The floating point
precision is one point you mentioned, the presentation medium is
another. But the trick is, to make the steps small enough so that they
make no difference. Just because we can't see the fleas on the elephant,
doesn't mean they are not there.

I'm not sure about the circle in openscad. It is handy for creating
hexagons, etc, and $fn and others get the resolution of the steps good
enough for my purposes, but with the higher resolution comes longer
processing time. I think that is the major problem, in particular with
curve fitting, it needs to be interactive. It seems that we want to use
openscad for things that fundamentally it is not designed to do. It is
not like many other cad programs, possibly like no other cad program,
but that is not a bad thing.

I'm not sure if openscad directly exports any file formats that are used
in high precision work, so it is possibly a moot point that I am making
wrt openscad.

Best wishes,

Ray

On 9/2/2022 4:20 PM, Raymond West wrote:

I suppose that it's an almost philosophical matter, but if I say "a
circle with radius 1 positioned at the origin", that's a digital
representation that is not dependent on discrete points.  Yes, any
particular presentation of that circle will probably turn into
discrete points, but that's an inaccuracy in the presentation, not in
the representation.

STL is accurate to about 0.1ppm.  That's enough to represent the height
of the Burj Khalifa to less than a tenth of a millimeter, or a car to
around a micrometer.

Is that high precision?

(And I wouldn't be surprised if other formats used double precision,
which is enough to represent the Earth to an accuracy of about a
nanometer.  That's not quite atom-accurate, but it's close.)

I would actually be more worried about OpenSCAD's internal grid snap
mechanism.