Loading
Hey! This thing is still a Work in Progress. Files, instructions, and other stuff might change!

STL to OpenSCAD python converter

by fma, published

STL to OpenSCAD python converter by fma Mar 22, 2013

Description

Here is a standalone version of the online STL to OpenSCAD converter, by Riham.

2014-04-06: added USE_FACES flag to generate polyhedron using "faces=" param, instead of "triangles=" (default enabled).

Recent Comments

view all

I uploaded a new release, with a flag to generate either "faces=" or "triangles=" param. Enabled by default, for OpenSCAD versions > 2014.03. Set to False if you use an older version.

Maybe an openscad version issue... Does it work if you replace triangles by faces?

Perhaps related to this warning:

The scad your tool produced worked _great_ in OpenSCAD on my desktop, but it doesn't render in Customizer (http://www.thingiverse.com/thi.... I can't see any error messages or warnings. But what I can see is that the geometry that's converted from STL doesn't render in Customizer, but the geometry that's "native OpenSCAD" renders.

Liked By

view all

Give a Shout Out

If you print this Thing and display it in public proudly give attribution by printing and displaying this tag. Print Thing Tag

Instructions

- save the python script
- make it executable
- convert STL using: ./stl2scad.py

Look at logre.eu/wiki/Convertisseur_STL_vers_SCAD for future updates.

Comments

You must be logged in to post a comment.

laird on Mar 30, 2014 said:

This tool is awesome! I just used it to generate OpenSCAD versions of a pile of STL files (for the e-NABLE project, http://enablingthefuture.org) and it worked perfectly!

FYI, I did get one warning, "DEPRECATED: polyhedron(triangles=[]) will be removed in future releases. Use polyhedron(faces=[]) instead." but it works fine in OpenSCAD 2014.03.

fma on Mar 30, 2014 said:

Thanks! I'll fix the warning...

lorenmcconnell on Apr 22, 2013 said:

I think I've found a bug which prevents this script from working for me on Win7.

I am using "Binary.stl" attached to Riham's "RTL to OpenSCAD Converter" as a test case.

The script fails at line 98 with the error "struct.error: unpack requires a string argument of length 12".

So, the script is getting an unexpected number of bytes from file.read, in the middle of parsing a vertex. After some debug, it seems this is caused by interpreting 0x1A bytes in the file as EOF and returning early from file.read().

To fix this, I made the following change to the script:

#inputFile = file(inputFileName)

inputFile = open(inputFileName, 'rb')

In the python documentation on "file()" it says, "When opening a file, it’s preferable to use open() instead of invoking this constructor directly."

Python documentation describes open() mode this way: "The default is to use text mode, which may convert '\n' characters to a platform-specific representation on writing and back on reading. Thus, when opening a binary file, you should append 'b' to the mode value to open the file in binary mode, which will improve portability. (Appending 'b' is useful even on systems that don’t treat binary and text files differently, where it serves as documentation.)"

In my testing, open() mode "rb" worked for both ASCII and Binary STL files.

fma on Apr 22, 2013 said:

Mmm, you're right! I'll fix that ASAP. Thanks for reporting :)

Anonymous on Apr 22, 2013 said:

I think I've found a bug which prevents this script from working for me on Win7.

I am using "Binary.stl" attached to Riham's "RTL to OpenSCAD Converter" as a test case.

I get the following output from the script:
Traceback (most recent call last):
File "debug2_stl2scad.py", line 150, in <module>
main()
File "debug2_stl2scad.py", line 140, in main
modules = parseBinary(inputFile)
File "debug2_stl2scad.py", line 98, in parseBinary
vertex = struct.unpack("<fff", "file()"="" "rb"="" "the="" "when="" #inputfile="file(inputFileName)" '\n'="" 'b'="" 'rb')="" (appending="" 0x1a="" a="" after="" an="" and="" append="" arguments="" as="" ascii="" back="" binary="" both="" by="" bytes="" caused="" change="" characters="" constructor="" convert="" debug,="" default="" describes="" differently,="" directly."="" documentation="" documentation.)"="" don’t="" early="" eof="" even="" file="" file,="" file.read().="" file.read,="" files="" files.="" fix="" following="" for="" from="" getting="" i="" improve="" in="" inputfile="open(inputFileName," instead="" interpreting="" invoking="" is="" it="" it’s="" keyword="" mad="" may="" middle="" mode="" mode,="" my="" no="" number="" of="" on="" open="" open()="" opening="" parsing="" platform-specific="" portability.="" preferable="" python="" reading.="" representation="" returning="" s="inputFile.read(3*4))" says,="" script="" script:="" seems="" serves="" should="" so,="" some="" stl="" systems="" takes="" testing,="" text="" that="" the="" this="" this,="" thus,="" to="" treat="" typeerror:="" unexpected="" unpack()="" use="" useful="" value="" vertex.="" way:="" when="" where="" which="" will="" worked="" writing="" you=""></fff",></module>

Anonymous on Apr 21, 2013 said:

I think I've found a bug, which prevented this script from working for me on Win7. As a test case, I used "Binary.stl" attached to Riham's "STL to OpenSCAD converter".

The script would terminate early with this output:

binary file
found 1512 triangles
Traceback (most recent call last):
File "debug2_stl2scad.py", line 148, in <module>
main()
File "debug2_stl2scad.py", line 138, in main
modules = parseBinary(inputFile)
File "debug2_stl2scad.py", line 98, in parseBinary
vertex = struct.unpack("<fff", "file()"="" "rb"="" "the="" "when="" #inputfile="file(inputFileName)" '\n'="" 'b'="" 'rb')="" (appending="" 0x1a="" 12="" a="" about="" an="" and="" append="" argument="" as="" ascii="" back="" because="" believe="" binary="" both="" bytes="" change="" characters="" constructor="" convert="" default="" descibe="" differently,="" directly."="" docs="" documentation.)"="" don’t="" eof="" even="" file="" file,="" file.read()="" files="" files.="" for="" function="" i="" improve="" in="" incorrectly="" inputfile="open(inputFileName," inputfile.read(3*4))="" instead="" interpreting="" invoking="" is="" it="" it’s="" length="" made="" may="" middle="" mode="" mode,="" mode:="" my="" number="" of="" on="" open="" open()="" open(),="" opening="" platform-specific="" portability.="" preferable="" prematurely.="" python="" read.="" reading.="" representation="" requires="" returning="" says,="" script.="" serves="" should="" so,="" stl="" string="" struct.error:="" systems="" terminating="" testing,="" text="" that="" the="" this="" thus,="" to="" treat="" unexpected="" unpack="" use="" useful="" value="" vertex="" was="" when="" where="" which="" will="" works="" writing="" you=""></fff",></module>

ajd4096 on Apr 9, 2013 said:

Many thanks to both of you!

This is an absolute life-saver for reverse engineering sketchup files.

fma on Apr 11, 2013 said:

:o)

steeve_becker on Mar 23, 2013 said:

whoooot :)

M_G on Mar 22, 2013 said:

It's always pleasant when things like this arrive JUST as you find you need them! Thank you for this fma

fma on Mar 22, 2013 said:

All credit goes to Riham! I was also looking for such tool...

Now, we can hack all designs ;)

Top