טבעונות ותכלית

On 3D Printing Description Languages

Introduction

3D printing is a new and exciting technology that allows us to create 3D objects designed using computer software. 

3D models can be manufactured by sending their description to a device. This device is much like a printer in the way that it controls a given space, only this time it is the volume of a cube, rather than a flat page. It also has an arm, much like a printer head, that emits a substance, normally initially liquid which quickly gets solidified. By building one layer on top of another, one can get a three dimensional object. For no better name, we call it a 3D "printer", though it does much more than this - it manufactures a real object. 

Picture of the ORDbot Quantum 3D printer. Source: Wikimedia

The notion of being able to create 3D objects is quite wild. It changes the way we think about manufacturing.  We no longer have to make plates and then create masses of things to justify the plates price. We can simply create things directly from a computer.. It is a bit like the change that happened to regular printing when there was a move to digital printers from offset printers.  Like that change, it will quickly lead to home-usage. People could generate items at home, manufacturing things from simple plastic rings, through building block toy sets, to anything they can imagine.

Quite obviously this also gives rise to options of generating things with different kinds of materials, and even get to the point of being able to generate…well…food with it. Provided that the right kind of materials can be found, obviously anything can be "printed".  This is quite a bit of Sci Fi, but it is definitely there in the pool of options.

The technology of 3D printing is still in its early stages though we can already see some good implementations. There are many riddles to solve as to the physical features of what can be created with these printers and how barriers can be overcome (silly things like gravity being in the way of just placing dots in thin air and a whole slew of other issues, like making the process fast and cheep).  

The methods of passing digital information from the computer to 3D printers borrow a lot from the fields of CAD (computer aided design) and 3D animation. 

I would like to propose, in this article, looking into other fields, in order to enhance the power of what's possible to describe to a given 3D printer, or improve the existing forms of descriptions. I will focus on 2D imaging and printing and Video compression.

I am going to assume some knowledge of computers graphics here. If you don't what a pixel is, you might need a guide here (I tried to write this first without taking that assumption…it was significantly longer).

Note that I am by no means a 3D printer expert. I'm quite decent in 2D printing and know a little bit about movie compression. It might be that what I'm suggesting already exists in some form…though I couldn't find anything like it. I would love to know about such things, b.t.w, hence the option to add comments below.

3D Reality

So, how does one describe an object to a printer? We'll take a couple of assumptions to answer for that:

1. That the printer arm "resides" in a certain 3D grid. For the sake of simplicity we'll decide that this grid is a certain cube, (or a Cuboid, if you must).
2. That this grid is made of separate points. Like pixels on a 2D images. It makes sense. The arm puts material in specific geometric dots, and it will have a certain resolution, and therefore there will be pixels there. So, the grid is made of dots in the 3D space, each in constant distance, so that we can refer to each dot by providing its coordinates in the grid.

Under these assumptions then describing an object to a printer simply means to state at each point of the object what should be. If it’s a printer of a single materials, simply describe whether there is materials or not - very much like black and white images. If there are multiple possible materials, and we can mix them even, say to create a specific color, than we should be able to tell what level of each materials should be at that point. We can think of the value at that point to be a certain code. This code can be the combination of color values, as is the case for color images, or simply the code of one of X number of materials that this printer can provide (but say, not mix). Whatever. The point is that we should have for each dot in the grid what to place.

This description can be put in a digital file, where the order of the dots is their order in this space. we can decide some order, say by running the X values on a given Y and Z, and than going up in Y for the next line and then its X values and so on until a single plain is described, then up one in Z to describe the next layer/plain etc.

This is exactly how we would think of a 2D photo image going 3D. We "scan" reality for the dots in a 3D grid, and just state what is there. Simple.

Given that file, the printer simply follows the grid in the same order as in the file placing materials here and there. It might need an alternative move pattern in order because of some physical issues (like gravity collapsing the-yet-printed object if we don't provide fillers) , but that's already the printer problem of how to go about it…not a problem with the description.

Describing 3D pixels

3D data description could get quite large if its left in its raw form. What can we do about it? We need some compression. It needs be trivial enough so a printer will not dwell too much on decompressing it while running, but it needs to be as efficient as possible.

2D imaging has some possible solutions to the same problem.. Images in 2D can be compressed using various methods which most familiar is the DCT compression algorithm implemented in JPG format. A reader of an image file, and so our printer, has to know how to decompress the image in order to show it. Example formats are JPG, PNG, TIFF etc. 

To describe 3D graphics we need something like this, but in 3D. First option, is to expand DCT to 3D. I don't know enough of the DCT technical details, but it might be an option.  Considering that 3D continuum behaves in the same way as a 2D continuum in being gradually changing unless it's an object that changes, I would think that such adaptation is possible.

We can also propose an alternative. Actually, we already have an area in digitized content that is 3D…simply not the space 3D. It's actually 2D of space and 1D of time. VIDEOS.

Video formats describe video as a series of images at a given constant value of frames-per-second - similar to our concept of resolution. It is true that it makes the time order special, which might hinder its ability to compress in the most optimized form (as oppose to the alleged extended DCT) , but it is already quite good in being of 3 dimensions, and is surely doing a good job in the 2D (it's can be essentially a JPG there). To use Video formats in 3D descriptions we need to simply think about one of the axis of space in the role of the time. And voila - we got ourselves a 3D file format, with all the good compression options.

We need to see that the assumptions taken about time in the particular format, are also good for the 3D dimension of choice in space.  Let's look at one of the formats and see if this can be done.

MP4 and H264

MP4 is one of the best known formats for video. It houses two sub-formats in it - one format for describing sound, and one format for describing video. 

H264, the format used to compress video in MP4 uses a notion of GOP to do a good compression over time. GOP (group of pictures) means that every group of successive frames in a movie is described by providing an initial frame in full (using a regular 2D compress) and later frames as differences from it. Each group is called a GOP. A movie is simply a series of GOPs. The notion of GOP is good for compression because the difference information is smaller, normally, than describing the frames in full. not the whole frame changes normally, unless there's a move from one scene to another.

Now, say we wanted to use H264 as a format for 3D printing, would we be right in saying that the same assumptions that make GOP a good idea for time would also work for a certain Z order, given that each frame describes the other two dimensions? I'd like to say that the answer is yes.

Why is that the case? Because much like time, the Z order in reality can be looked at as a continuum and so provide good compression in the GOP style. Imagine a "cube" in reality. You could look at it as a series of 2D frames on a given z order at a certain resolution (high enough to seem a continuum). Same conditions apply - there are change sometimes between one frame and another but they are either gradual or not at all, unless passing from one object to another. Same as it happens with time.

Another aspect of H264 that might become useful

H264 method of GOP has one other interesting aspect. You probably know that you can skip from one position in the video to another. This is quite interesting because most compression formats are one-way and require you to decompress the whole data up to a given point in order to use it. However, since H264 uses multiple GOPs to describe a full movie, then if you want to see a specific second in the video then skip to the nearest preceding GOP and then just calculate the image from there based on the following frames.

This saves a lot of time in skipping from one time in the movie to another.

Why is this idea important? Because it means that we do not have to print an object from top to bottom using one head. We could employ several arms to print an object, and so save time. Imagine using 2 arms instead of one - one going from top to middle, one going from bottom to middle. We can cut the time to print to half. That's not too bad.

STL

So I was having my happy thoughts about how movies are probably used as a format in 3D printing. Starting to read I saw that I was way off.

Formats in 3D look completely different than this notion. Let's look at STL.

STL is the most prominent format in describing 3D objects, and what 3D printers use now as input.

The way STL is describing reality has to do with a process called triangulation. You can read about the specific some place else, but the basic idea that 3D surfaces can be described as a series of triangles in the 3D space. Hence, a 3D object can be described by describing its surface, which in turn is described by a series of triangles. Here is an example of a triangulated description of a dolphin image:

Dolphin Triangle Mesh. Source: Wikimedia

STL has two clear benefits, which makes it a sensible choice:

1. Most CAD applications, which are the current primary source of work for 3D printers, use STL. Triangulation is a common way to work with 3D objects allowing for fast rendering of 3D surfaces and animation. This is OK because CAD Applications always emulate objects, not create actual objects. Hence they only care about how the external surface, what's visible, appears. 
2. It's efficient. The equivalent in pixels description would be to describe all pixel coordinates where the surface is. Quite obviously stating a triangular area as a combination of 3 vectors is more efficient than describing it stating all the points that are within that triangle plane.

OK. So then I figured, why not really use STL, which is much more efficient than a parallel 3D pixels description like I was proposing earlier.

Well, I guess that as long as printers use just 1 material, and that triangulation is simple to do on any object that we can think off…yeah, why not.

But, if we want to use multiple materials than using a format that just describes shapes is not enough.

If gradual change is required in the materials composing an object (say an internal "gradient") than STL would not be enough.

It is for that reason exactly that 2D imaging doesn't always use just vector graphics to describe any image. 

It also seems that existing printer have to translate STL to pixels anyways in order to do the final print, well…why not give them the pixels directly then?

It also requires that my application of 3D will be able to do the triangulation. It is probably simpler for the application I'm building to go directly from my vector graphics description to pixels, not having to conform to triangulation (maybe I prefer other primitives such as balls and cubes) and triangulation computing.

So I'd think that at least as an option, if not a complete replacement, a pixel description and compression as I suggested is necessary.

Postscript and PDF going 3D

In order to allow both pixel and vector description (and possibly also triangular description) all living together in 3D, and using what tool is good for the moment, I'll move to looking at some other 2D printing formats.

PostScript and PDF are formats used in 2D printing to describe pages and the graphics on them. Postscript and PDF files are translated by a software named "RIP" (Raster image processor) to pixels. In both languages we find such elements as primitives - rectangles, triangles, curves, lines  - as well as text and fonts and also pixel images.

Since the "RIP" is common and normally provided with the printer a designer software can focus on creating Postscript and PDF files, not having to know how to do the pixel translation (or in our case, triangulation or pixels), but rather work with the higher level elements.

This makes building designer applications for the purpose of printing A LOT easier, and so there are many that do this.

We can have the same in 3D. Instead of requiring low level format like STL we can extend PS or PDF to live in the 3D, by following some simple steps:

1. All vectors and coordinates become 3D
2. We support images of 3D
3. We support some new primitives that are 3D - cube, ball, etc.
4. RIP is adjusted to emit 3D pixels

[in simple I meant - philosophically - it's one hell of a write-up].

Note that in addition to designer driven content (like one created in CAD and possibly in a future "InDesign" or "Photoshop") we can consider automated creation of pieces where such PDF and PS files for 3D are created directly. Anyone familiar with VDP softwares? Variable data printing is by now a common method to create automatically batches of printer pages that are slightly different copies providing personalized information to multiple recipients. Clearly once we can automate using high level features, it would be easy to automatically create such pieces. Consider automatic creation of a batch of lego cubes each with a different person name, (or multiple like them), as a promotion for your product. Consider being able to do that at home.

Something special about 3D fonts. Note that the existing TTF and OTF can also be, in a simila manner, expend to support 3D glyphs. Some other elements of the fonts may also change - like kerning definition (spacing between letters) should become now 3D, so designer applications can automatically determine the right space between letters.

Sketch of a 3D Font. Source: Maayankah (that would be my sister)

Another notion in 2D print files that may be "understood" in 3D is that of a page. A logical page in a printer is simply where multiple objects reside. In the same fashion, giving some physical adjustments, we can think of printing multiple objects in the same run. It would be like manufacturing a single set together, that can be easily broken later by the end-user to the different pieces. Printing multiple objects like this allows for later simplified automated packing. On packing we'll discuss in the next (and last!) section.

Automated workflow

One last comment. 2D printing workflow is a lot like manufacturing. It's not just about the printing part. It is also about binding the pages and applying finish. Later sorting the pages per zip codes and mailing that. All this is done, if possible, automatically. Nowadays there is a standard for describing workflows. It's called JDF. There is also a common protocol for sending status messages as to the readiness of the particular step in the workflow. It's called JMF.

It's quite trivial to imagine that sometimes the same automated workflow will be required in 3D printing. So I'm just saying that also here there's something ready in 2D…possibly just waiting to be picked.

Conclusion

Moving forward with 3D printing there are quite a few elements that may be learned from 2D printing and video compress. I was trying to propose some points. Example as the usage of video files as 3D images, and fonts/primitives and images in PS/PDF formats as  possible higher level methods that I expect to make it easier for software vendors to develop for 3D printers.