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 <openscad@jordan.maileater.net> 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 > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

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 <drifter.frank@gmail.com> 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 < > openscad@jordan.maileater.net> 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 >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >