Additional File Types (Wavefront OBJ, IGES, and/or STEP) file types?

[cakeller98]

Not sure if the library you're using allows you to trivially add the Wavefront *.obj file type, but I prefer using this file type as it is a bit more robust than stl, and is almost as widely used... way more common than AMF for sure.

One cool thing about OBJ, not sure if STL can do this, but... Obj can have named bodies, which allows for these bodies to, in theory, be designated as support, or not, or for multiple colors.

[tlalexander]

Also IGES and STEP would be great. Anything that's not STL would vastly improve the entire community. If people were encouraged to use formats like IGES (not familiar with OBJ personally) then sharing would be way easier. Right now people typically only upload an STL to thingiverse, which is a nearly uneditable format. If people could slice files in more editable formats, they might stop using STL, and if people post more editable files on thingiverse then more people can collaborate and make changes.

I definitely think that supporting non-mesh formats is a must for improving the community. http://en.wikipedia.org/wiki/IGES http://en.wikipedia.org/wiki/ISO_10303 (step)

[alranel]

OBJ was in my plans already, but the other two are not and I accept patches for them.

[cakeller98]

I think STEP and IGES are pretty difficult to use for this type of thing. I know from importing them into CAD software, there are so many flavors and tolerance issues you can end up with difficult to diagnose errors.... even sometimes importing a STEP or IGES file back in to the same program that created it can have less than perfect results.

Perhaps there is a library that has already done the heavy work of being able to slice NURBS surfaces directly? if so - could that work? do you need to be able to look at the geometry more than just as slices?

[aewallin]

most of the opensource CAD efforts seem to use OpenCascade (http://www.opencascade.org/), which should have IGES/STEP support. You could maybe make a perl/python module that uses opencascade to read step/iges and outputs STL (given some triangle tolerance specs). For the CAM/toolpath algorithms there are two camps. In practice it seems everyone works on STL-files, because it's robust and memory/cpu is cheap. In theory (academic papers!) you could slice NURBS directly and do all the math without describing complex surfaces as a bunch of triangles. Most toolpath generation is a mix of both of these techniques I guess..

[alranel]

@aewallin, given memory's cheap and life short... NURBS slicing can wait ;) Also thanks for being here, you have much experience in that field.

[alranel]

OBJ done!