Functions to import STLs, PNGs as data?

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

Functions to import STLs, PNGs as data?

JordanBrown
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?


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

Re: Functions to import STLs, PNGs as data?

cacb
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

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

Re: Functions to import STLs, PNGs as data?

Ronaldo
In reply to this post by JordanBrown
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:





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

Re: Functions to import STLs, PNGs as data?

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


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

Re: Functions to import STLs, PNGs as data?

JordanBrown
In reply to this post by Ronaldo
On 3/3/2021 5:23 AM, Ronaldo Persiano wrote:
Something like that was already proposed by Parkinbot 4 years ago:


No surprise.  It's not a terribly exotic concept.

But I'm kind of looking for a project...

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

Re: Functions to import STLs, PNGs as data?

tp3
In reply to this post by JordanBrown
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.

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

Re: Functions to import STLs, PNGs as data?

JordanBrown
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.


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

Re: Functions to import STLs, PNGs as data?

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

Re: Functions to import STLs, PNGs as data?

nophead
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 <[hidden email]> 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
[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: Functions to import STLs, PNGs as data?

JordanBrown
In reply to this post by tp3
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.


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

Re: Functions to import STLs, PNGs as data?

frankv
In reply to this post by JordanBrown
I have some Java code that reads an STL and outputs it as text to include in a .SCAD file, if that would be useful to anyone.

On Thu, Mar 4, 2021 at 10:02 AM Jordan Brown <[hidden email]> wrote:
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.

_______________________________________________
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: Functions to import STLs, PNGs as data?

nophead
polyhedron() could error just in F6 or render(). That is when it matters and would stop the endless list of why does my STL preview but not render?

On Thu, 4 Mar 2021 at 03:49, Frank van der Hulst <[hidden email]> wrote:
I have some Java code that reads an STL and outputs it as text to include in a .SCAD file, if that would be useful to anyone.

On Thu, Mar 4, 2021 at 10:02 AM Jordan Brown <[hidden email]> wrote:
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.

_______________________________________________
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

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