Functions to import STLs, PNGs as data?
It's hard (which is to say impossible) to take OpenSCAD geometry and
extract any information about it.
However, it doesn't seem like it would be hard to, say, design a
function that would read an STL and return it as an array of faces.
Similarly, one could read a PNG and return it as an array of pixel values.
Would people find functions like those useful?
Would the maintainers be interested in accepting such a thing?
On 03.03.2021 07:09, Jordan Brown wrote:
It's hard (which is to say impossible) to take OpenSCAD geometry and
extract any information about it.
However, it doesn't seem like it would be hard to, say, design a
function that would read an STL and return it as an array of faces.
Similarly, one could read a PNG and return it as an array of pixel values.
Would people find functions like those useful?
Would the maintainers be interested in accepting such a thing?
The main problem as I understand it is that the philosophy of the
OpenSCAD language does not appear to allow such features (I could be
wrong). You can import an STL and use it in boolean operations, but you
can't access the details of it. After all it is a declarative language.
But yes, I think it would be useful. Of course, if you made such a
feature you would need to decide whether to treat the returned data as a
triangle soup or as a polyhedron. This is not an issue for other formats
like OBJ or OFF, because they are polyhedra in the first place.
In AngelCAD you can import polyhedra from external files:
polyhedron@ poly = polyhedron("myfile.obj");
Then you can access the vertices and faces in "poly". It would be
conceivable to do similar things with image files like PNG,JPG and more.
I tested such a feature at one stage, but didn't include it as I didn't
find sufficient practical use for it. I could be wrong about that too.
Carsten Arnholm
It's hard (which is to say impossible) to take OpenSCAD geometry and
extract any information about it.
However, it doesn't seem like it would be hard to, say, design a function
that would read an STL and return it as an array of faces. Similarly, one
could read a PNG and return it as an array of pixel values.
Would people find functions like those useful?
Something like that was already proposed by Parkinbot 4 years ago:
http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20123.html
On 3/3/2021 2:26 AM, Carsten Arnholm wrote:
The main problem as I understand it is that the philosophy of the
OpenSCAD language does not appear to allow such features (I could be
wrong).
OpenSCAD does not have any way to extract information out of geometry -
and can't, without a major rewrite. (It doesn't know very much about
the geometry until after the "execution" is completely done.) Even
render() doesn't really do anything while the program is still running.
But I'm not talking about geometry. I'm talking about a function that
would read a file and return data. I'd say the language design is
neutral on such a concept.
You can import an STL and use it in boolean operations, but you can't
access the details of it. After all it is a declarative language. But
yes, I think it would be useful. Of course, if you made such a feature
you would need to decide whether to treat the returned data as a
triangle soup or as a polyhedron. This is not an issue for other
formats like OBJ or OFF, because they are polyhedra in the first place.
For STL, the data returned would necessarily be triangle soup, because
that's what STL contains. The natural form would be an array of
triangles, each being an array of vertices, each being three numbers.
Alternatively, it could return a more polyhedra()-friendly form of an
array of points (each being an array of three numbers) and an array of
faces (each being an array of point indexes).
In AngelCAD you can import polyhedra from external files:
polyhedron@ poly = polyhedron("myfile.obj");
Then you can access the vertices and faces in "poly".
Yes, this would probably be much like that, only without having a
language-supported data type.
It would be conceivable to do similar things with image files like
PNG,JPG and more. I tested such a feature at one stage, but didn't
include it as I didn't find sufficient practical use for it. I could
be wrong about that too.
I get the impression that the need for it is not frequent, but not never.
On 3/3/2021 5:23 AM, Ronaldo Persiano wrote:
Something like that was already proposed by Parkinbot 4 years ago:
http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20123.html
http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20123.html
No surprise. It's not a terribly exotic concept.
But I'm kind of looking for a project...
On 03.03.21 17:32, Jordan Brown wrote:
I'd say the language design is neutral on such a concept.
Yes, it has nothing at all to do with the language.
Also considering there are already functions that do such
a thing, I'm not sure how that is even controversial.
For STL, the data returned would necessarily be triangle
soup, because that's what STL contains.
I don't think that would be acceptable. The return data
structure should be the same for all the file formats (well,
maybe one for 2d and one for 3d, but not different for STL
vs. OBJ).
ciao,
Torsten.
On 3/3/2021 8:41 AM, Torsten Paul wrote:
On 03.03.21 17:32, Jordan Brown wrote:
I'd say the language design is neutral on such a concept.
Yes, it has nothing at all to do with the language.
Also considering there are already functions that do such
a thing, I'm not sure how that is even controversial.
Which functions are you thinking of? I don't see any functions on the
cheat sheet that read files. There are modules, but that's a little
different.
For STL, the data returned would necessarily be triangle
soup, because that's what STL contains.
I don't think that would be acceptable. The return data
structure should be the same for all the file formats (well,
maybe one for 2d and one for 3d, but not different for STL
vs. OBJ).
If one file format includes connectivity information and another
doesn't, it's hard to see how the two can be represented the same.
Perhaps the data returned for OBJ would be a superset of the data
returned for STL, with a triangle soup plus connectivity data.
That suggests that the returned structures should be designed for
extensibility. The "object" mechanism would be helpful there.
On 03.03.21 22:01, Jordan Brown wrote:
Which functions are you thinking of? I don't see any
functions on the cheat sheet that read files. There
are modules, but that's a little different.
Yeah, they seem to be missing from the cheatsheet :-(.
dxf_dim() and dxf_cross():
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/General#Getting_input
ciao,
Torsten.
Currently the only STLs that can be imported are those where you can
unambiguously stitch the triangles together to get a manifold. So an import
function could return the two lists needed by polyhedron to draw it.
On Wed, 3 Mar 2021 at 21:06, Torsten Paul Torsten.Paul@gmx.de wrote:
On 03.03.21 22:01, Jordan Brown wrote:
Which functions are you thinking of? I don't see any
functions on the cheat sheet that read files. There
are modules, but that's a little different.
Yeah, they seem to be missing from the cheatsheet :-(.
dxf_dim() and dxf_cross():
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/General#Getting_input
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 3/3/2021 1:05 PM, Torsten Paul wrote:
dxf_dim() and dxf_cross():
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/General#Getting_input
Yeah, it would be sort of like those, but returning a lot more data.
On 3/3/2021 3:33 PM, nop head wrote:
Currently the only STLs that can be imported are those where you can
unambiguously stitch the triangles together to get a manifold. So an
import function could return the two lists needed by polyhedron to
draw it.
That's a likely representation, though I wouldn't expect the import
function to do all that much in the way of sanity checking.
Side note: Long ago I opined that polyhedron() should reject invalid
polyhedra - in particular, those that have faces reversed or do not have
fully connected faces. (Or some other invalid cases.) Having played a
bit more with polyhedra, I now think that I was mostly wrong. I do
think that it would be good for it to somehow tell you that your
polyhedron is no good, but maybe a warning would be enough. While
you're building up the data for a polyhedron, it's very useful be to
able to see the "work in progress" - missing faces, backward faces, and all.