Standard Sliced Format?

[Dave Cowden]

hello, all:

I saw the CS1 GPU- based slicer demo-- way cool!   I'd like to help!

I have been working on a decent slicer for some time now, but with two goals in mind:

(1) allow using STEP files as input intead of STL

(2) figure out a fairly standard file format so that machine specifics do not create a 5-step printing process.

(3) figure out a way that printers can print files without host software, much like network attached printers can print stuff today.

My current software uses OpenCascade and pythonocc because that way i can read and manipulate either STL or STEP.  Then, i plan to produce PNG files for slices ( in the case of DLP printers), or toolpaths for FDM printers.

It looks like the CS1 software is aiming at do-it-all host software-- which is definitely the optimal solution in terms of number of steps.  That said, it needs STL, and it requires a lot of horsepower to slice ( GPU is a sweet trick though! )  

The question i have asked myself for a while is:  "what is the 3d equivalent of a PDF for 2d"?  Is it a STEP file, which means host software should direct slice a STEP file? Or is it a sliced file ( which means host software only plays back toolpaths ? ) Or is it gcode?

In the FDM space, printers are already achieving item 3-- printing from an sd card using marlin.  For them, the 'PDF' of 3d printing is a gcode file. But there are two problems:

(1) it doesnt work for DLP, which needs images, and

(2) it so so machine specific that everyone has to create it again-- IE, not really a PDF at all.

I think there is a need for a 'standard' slice format-- which sends png images for DLP and toolpaths ( maybe via svg ) for FDM. I think the printer firmware and/or host need to do the rest.  The goal should be to have as few machine parameters as possible required for slicing-- and, in fact, perhaps a single format ( sliced at a very thin interval) would work, because then printers  could adjust upwards if they do not have the resolution.

Thoughts? I'm happy to help!  This is cool stuff!

Regards,

Dave

[Hradec]

hello, all:

Hi there!

 

I saw the CS1 GPU- based slicer demo-- way cool!   I'd like to help!

help is always welcome!!!

 

I have been working on a decent slicer for some time now, but with two goals in mind:

(1) allow using STEP files as input intead of STL

Why STEP? STL is more widely used, and people in the 3D Printing community is used to it, not to mention is the main file format used on thingverse.com.

I also included Wavefront OBJ support because its widely used by 3D Artists that use tools like Maya, Zbrush and Mudbox. (although my OBJ loader needs some work right now)

Anyhow, I wouldn't mind adding support to STEP as well... if you want to work on that, just take a look at the stl.py and obj.py files located in glViewport folder of the host svn depot. 

http://code.google.com/p/chemshapes/source/browse/chemshapes/trunk/host/glViewport/stl.py

http://code.google.com/p/chemshapes/source/browse/chemshapes/trunk/host/glViewport/obj.py

booth of those loaders are derived from the mesh class, which is in mesh.py:

http://code.google.com/p/chemshapes/source/browse/chemshapes/trunk/host/glViewport/mesh.py

take a look at mesh.py and you'll pretty much get the idea of how to implement your own.

 

(2) figure out a fairly standard file format so that machine specifics do not create a 5-step printing process.

I assume this make sense once you figure number 3?

 

(3) figure out a way that printers can print files without host software, much like network attached printers can print stuff today.

I have being thinking about this one for a while, but not much luck since in the DLP case, we require a high-resolution buffer to display the images, which can't be done with a simple 8 bit micro-controller like an arduino.

What I figure is... because you need a large and fast framebuffer which can output an image of 1920x1080 through an HDMI connector, there's no way to scape from a computer, even if an embed one. Following this logic, then we can assume, if we're going to use a embed computer, like an arm CPU with HDMI, why not use an embed one that have an GPU?!?

And one with a GPU, we can run our slicer in it, in realtime!! Just save out the mesh with a small XML file and you're done!

We're really excited about the Rasberry PI project, which brings all that we would need to replace the current arduino implementation, and comes with a fairly decente GPU, 26 I/O pins... just perfect!!!

 

My current software uses OpenCascade and pythonocc because that way i can read and manipulate either STL or STEP.  Then, i plan to produce PNG files for slices ( in the case of DLP printers), or toolpaths for FDM printers.

That;s really cool... I never heard about pythonocc before... it sounds awesome!! How fast it is to load STL files? does it read OBJ? 

 

It looks like the CS1 software is aiming at do-it-all host software-- which is definitely the optimal solution in terms of number of steps.  That said, it needs STL, and it requires a lot of horsepower to slice ( GPU is a sweet trick though! )  

Yeah... The GPU essentially just JUMPS over the pre-process step... it allows for a instantaneous  "load and print"  method, in the same fashion as a normal paper printer does... And that's the goal!! Make 3D printer simple as normal paper printer is these days!!

And it makes perfect sense for DLP printers, since you require a computer to print anyway since you need the 1080p HDMI video buffer to control the DLP chip, and theses days, all video boards come with GPU, so... it just makes sense!!

 

The question i have asked myself for a while is:  "what is the 3d equivalent of a PDF for 2d"?  Is it a STEP file, which means host software should direct slice a STEP file? Or is it a sliced file ( which means host software only plays back toolpaths ? ) Or is it gcode?

The way I see it, an 3d Model format like OBJ or STL is the perfect "PDF" type of file, since it's way smaller than slices, specially if you're doing a high-res printing, like 40 or 20 microns... If you can send and simple OBJ directly to the printer controler, and the controller takes care of slicing and everything else, that's the perfect file format, in my opnion!!!

The idea of using a raspeberry pi as a controler for the printer is exactly that.. the host software will just save the model as an STL, adding some XML data to the end of the STL file, which sends all the configuration done by the user in the host software. 

then, the printer software running on the rasberry pi would just load that STL, strip the bottom XML to configure itself and print just like the host software would do! essentially, the software in the rasberry pi would be  a full CS1 Host, without the UI! 

 

That's my plan, at least... assuming the rasberry pi will become available some day... :)

In the FDM space, printers are already achieving item 3-- printing from an sd card using marlin.  For them, the 'PDF' of 3d printing is a gcode file. But there are two problems:

(1) it doesnt work for DLP, which needs images, and

(2) it so so machine specific that everyone has to create it again-- IE, not really a PDF at all.

indeed... I have a huxley and every new print is a new chalenge!! LOL

I think there is a need for a 'standard' slice format-- which sends png images for DLP and toolpaths ( maybe via svg ) for FDM. I think the printer firmware and/or host need to do the rest.  The goal should be to have as few machine parameters as possible required for slicing-- and, in fact, perhaps a single format ( sliced at a very thin interval) would work, because then printers  could adjust upwards if they do not have the resolution.

Again, even for FDM printer, the embed CPU/GPU is the solution, in my opinion... As I'm using GPUn today to slice geometry, I already have in my head some ideas of using GPU to generate toolpath from those slices... 

Imagine that... slicing geometry directly to toolpath in realtime! but that's definetely not for now... :)

 

Thoughts? I'm happy to help!  This is cool stuff!

I would really like to heard more about your software and pythonocc... I'm really interested in a faster way to load STL/OBJ files, specially to be able to load HUGE models exported from softwares like ZBrush and Mudbox, were they can get up to Gygabytes of binary data!!! And THOSE are the ones that are perfect to be printed in a high-res printer like the CS1, so we really need a faster way to load then!! 

 

Nice hear from you, Dave... let's definitely keep in touch!!!

cheers...

-H

[Henrique Muringa]

Hey Dave!!!

Nice to see you here!!!

=]

[Dave Cowden]

Hi, Hradec, thanks for the thoughts.

I agree Raspberry PI is a great platform to move towards, regardless.  

RE: STL, There are three reasons i'm not liking it:

    (1) leaky meshes, too much possibility for errors

    (2) huge file size to represent curved surfaces

    (3) inability to send efficient instructions for motion control ( billions of tiny lines intead of an arc )-- this is of course interestingly not an issue for DLP process !

There is a task force right now led by Hod Lipscomb at Cornell, where they are designing "STL 2.0" called AMF-- they solution they have come up with is a reverse compatible format that allows several features that are nice:

     (1) vertex normals allow creating 'curved' triangle patches to approximate spheres better

     (2) ability to specify materials

     (3) ability to specify combinations of solids

     (4) solves leaky meshes but not sure how exactly

     (5) specify colors

     (6) metadata

http://en.wikipedia.org/wiki/Additive_Manufacturing_File_Format 

I am not a huge fan of the 'curved triangles' but maybe this is the way to go? 

[Hradec]

Hi, Hradec, thanks for the thoughts.

hey there.. np!

 

RE: STL, There are three reasons i'm not liking it:

    (1) leaky meshes, too much possibility for errors

humm... I notice that there's tons of "bad" STL... your're right!

 

    (2) huge file size to represent curved surfaces 

    (3) inability to send efficient instructions for motion control ( billions of tiny lines intead of an arc )-- this is of course interestingly not an issue for DLP process !

Yeah... on the DLP side, I think booth of then are not that big deal... apart from big file size, which increases loading time.

Also, as we need an image, we need to tesselate the curves anyway, so I actually prefer to have a "triangle only" mesh since I don't have to tesselate it myself. 

There is a task force right now led by Hod Lipscomb at Cornell, where they are designing "STL 2.0" called AMF-- they solution they have come up with is a reverse compatible format that allows several features that are nice:

     (1) vertex normals allow creating 'curved' triangle patches to approximate spheres better

hummm.. interesting indeed... although, again, it creates overhead on the software that will render the mesh. 

Although, if we think about this in GPU terms, considering OpenGL 3.0 which brings geometry shaders, THEN things start to look PRETTY DAMN INTERESTING, since we can do the tessellation in the geometry shader... pretty much like subdivision surfaces! 

It kinda falls into my plans, since I wan't to implement GPU Subdivision Surface associated with displacement vector maps so one can export a low-resolution .OBJ mesh and a vector displacement map out of ZBrush/Mudbox  and load booth  in the Host Software, which will re-construct the original "insane polycount" mesh using the GPU geometry shaders.

 

     (2) ability to specify materials

     (3) ability to specify combinations of solids

     (4) solves leaky meshes but not sure how exactly

     (5) specify colors

     (6) metadata

Metadata is a must for sure!! That would solve the need for an xml file to submit a mesh to a GPU enable printer controller!

 

http://en.wikipedia.org/wiki/Additive_Manufacturing_File_Format 

I am not a huge fan of the 'curved triangles' but maybe this is the way to go? 

Maybe... Although, I would argue if this is not the same functionality currently found in Subdivision Surfaces. Catmul-clark one allows for infinite levels of subdivision, with hierarchical modification of then, including edge creases. One could very well use it to represent curved triangles in the same way... 

This describes the pixar implementation, which follows catmul-clark one: http://graphics.pixar.com/library/Geri/paper.pdf

cheers...

-H

[Dave Cowden]

Could be,but the AMF format has the buy in from a who's who list of 3d cad vendors and machine vendors.  I suspect that if the AMF format is 75% good or better, its a better bet to use it rather than roll a different one against the grain, right?

[Hradec]

well, it depends on your field... That does make sense in the CAD/CAM field, but on the artist field, people is more used Subdivs, displacements, etc.

So, ideally, support BOOTH is the way to go, so we cover booth fields! ;)

Booth are essentially the same, so once we develop support to one, the other will be easy anyway...

My point is more about why re-invent the well, you known? LOL... But I always forget about annoying things like patent fees, politics, etc...


-H
blog   home

[3DLPrint]

Hi group,

> The question i have asked myself for a while is:  "what is the 3d
> equivalent of a PDF for 2d"?  Is it a STEP file, which means host software
> should direct slice a STEP file? Or is it a sliced file ( which means host
> software only plays back toolpaths ? ) Or is it gcode?

Ok The answer is actually simple and it may just work. It is calles a
SLC file.
It is directly the contours of the object - pre sliced. All that is
left is to read it and fill the core and back space with color.
Also if you get a "leaky" slice it is easily fixed as it is only
contours and your cad should be able to connect the gap with line/arc/
blend/ whatever you choose.

PZ.

[Nuri Erginer]

I think SVG can also do the Job.

[Hradec]

Those formats are vector-based. I really don't think a vector-based slice is the best option to print high-resolution models, like the ones modeled in ZBrush.

I'm still more inclined to send the complete 3d model as STL/OBJ with the print setup as xml to a GPU enabled printer controller (Rasberry PI!!) so it can slice it as it prints.
my 2 cents...

:)
-H