Prosposal for a novel open source project concerning 3d printing

I recently wrote an article that suggests the development of a novel type of 3D file format that may be of great use for the 3d printing community:

Article "Why there is a need for a new 3D file format" by Gunnar Schulze

There, I describe that a gap exists between the world of CAD files and programs and the world of STL-type vertex-mesh-style files and that an appropriate file format in combination with an appropriate viewer/converter could help to increase the usefulness of 3D printing in general. Since there are also other discussions about similar topics in this forum, so I think it could be of interest for you.

As I pointed out in the article, the development within an open source project would be desirable. Therefore I would like to start a discussion about this topic and invite you to write your opinion.

I don't think the type of file format you're talking about could be saved into from a high-level CAD package without additional information. In order to have a small (say, less than a couple hundred) number of variables, you'd have to have the designer choose which the end-user can modify. With even fifty or so variables, the formulas for the locations of the individual points (which in turn define the triangles) would become unmanagably complex - as in complex enough you'd need a turing complete language to describe them.

Interestingly enough, you compared it to PDF, which is fancy postscript, and postscript IS a turing complete language. It's also a poor example for customization. PDF is a print-ready format, and completely sucks as anything else. It's the worst choice for distrubuting documents that will be read electronicly. This is despite Adobe's attempts to turn it into something else. There are extensions and such that make it somewhat customizable, but they don't always work correctly, are poorly designed, and work only with adobe's proprietary software, not with the plethora of third-party PDF viewers. PDF fill-in forms are a particularly poor choice. For anybody not using MS windows it's far, far easier to print it, fill it in by hand, and scan it.

Uhm, oops, sorry about the rant there, I hate PDF format almost as much as I hate java. PDF is absolutely great if you want to print something out somewhere else - convert to PDF, send the file, and print it at your destination. Unlike word documents, HTML, or indeed ANY other format, you can be sure that it will look on paper precisely as you intended. Any attempt to use PDF for any other purpose is misguided at best.

Err. Not done ranting I guess.

OK! Back to the topic.

There exists already a format that does what you describe. It's called "openscad" and is already in heavy use in the reprap world. As I said before, due to the extra design input required to make the described format, you'd pretty much need a turing complete language to store your point definitions in. Openscad is that language. It's not completely mature yet, but is already useful - the prusa mendel is designed in openscad, and can thus be easily adjusted for different printable areas, rod sizes, etc.

There IS a need for higher-level generators for this though. I imagine that a high-level CAD package could save to openscad format without too much difficulty. The designer would still have to choose which numbers to expose to the end user and which to leave as constants. And they'd still have to test a few different values to make sure the final object still made sense. For instance, a larger object may need thicker walls, and placement of holes would have to change for smaller objects, but change in relation to what?

Anyway, I don't think this problem is solvable by just a file format. It would be nice to have a more universal CSG file format, but I think there are a couple of proprietary formats that have become universal enough to almost qualify. The gaps between the ways that the different CAD programs understand things may prevent anything with higher-level information than a simple CSG from being universal.

Have you thought about more extended printer capabilities? For instance, people have made repraps that have a wire tool head capable of embedding wire in the finished product. That can't be described by a STL file though. And other things will come, eventually we'll have embedded electronics, valves, and other objects. Different blends and colors of plastic. And other things that I've probably not though off. Control over internal stresses? Fiber alignment direction? A description of the stresses that will be applied so the printer can put plastic just where needed on the inside of the object to get the needed strength?

Anyway, something will have to happen to enable some of those capabilities, but I for one don't know what it'll look like. Maybe openscad will evolve to have several "virtual layers" which are exported separately and sliced by the printer, and combined into commands for the various mounted tools.

---

--
I'm building it with Baling Wire

jgilmore, thank you for answering to my posting. I want to give my opinion to some of the points you address.

You say, you think that turing completeness would be required in order to manage the high amount of complexity of the file format I suggest. Although turing completeness would certainly be a nice feature of this format, I think that the complexity of the point definition is not such a big problem as you say. The reason for this is the possibility of relative definitions among the points (and/or additional helper points or structures). If the object has e.g. 50 external parameters this does not necessarily mean that for every point a function of 50 variables has to be evaluated. Instead, in a general situation, only functions with a few parameters will be used to define the position with respect to other points that depend on another few parameters and so on. The only thing that is needed is a defined order among the points in which they are evaluated. This evaluation could then be done in one single run, and no loops or real turing completeness would be required. A (crude) analogy would be the position definition of single elements of a website by a browser. Of course, adding turing completeness would improve functionality in many ways but it is not necessarily needed in a first standard definition.

You further mention different proprietary CSG file formats, that work as quasi-standard today. I think, the type of surface construction structure in the file doesn't need to be restricted to vertex meshes. CSG surfaces are just another class of object definitions that could be used. A good concept would combine different types of surface definitions under a common structure. The problem with proprietary systems is that they will only become popular as their software is distributed for free. For illustration of this effect I mentioned the pdf format (and not for comparing its technical structure, that is indeed missing the kind of user-defined adaptability I talk about).

The OpenSCAD project is in fact a good approach in the direction I propose to go. I have to admit that I need to take a closer look to it, but from a first point of view the "program language" part of it covers the "object definition" part a bit too much. And as you already noticed, a high-level viewer/generator is missing (at the moment) that would help to make it attractive for more users.

I think solid material features (as material/color/density gradients and so on) are another aspect that will become more important in the future. The way of dealing with it will certainly need some new concepts, but here again an well-defined (and well-established) file format with the capability of including these properties will certainly be of use.

Along the lines of openscad, there's POVRAY. POVRAY has been around for ages (since the early eighties at least) and is a quite well-developed language. Of course, it's got lots of cruft, and isn't supported outside of it's tiny little ray-tracing world. It is used as a ray-tracing engine by blender and others, (so obviously blender generates POVRAY language) and there are other front ends designed to do much the same.

Like many other tools developed for 3D graphics rather than CAD though, it has several problems (non-manifold objects, for instance) that make it less than ideal for CAD. Examining it and the tools designed for it might be educational though.

I don't know if there are any tools that read it, give the user a GUI to manipulate things, and write it back out. That'd be a bit of a trick.

Great response (very understated) to the rant about PDF. I appreciate your restraint.

Triangles are a horrible way to transfer CAD designs, they lose to much information. To get the simpler approach that you talk of, it would probably be simpler to store the original CSG information anyway. Triangle meshes are seldom used for CAD unless that's what you had to start with, or you're using cheap tools that can't do anything else.

---

--
I'm building it with Baling Wire

How about using the HDF format, It is well documented and open source. One main field of application is FEM, where it stores both the, the mesh as well as the results, but it can store any kind of data nedded.
[www.hdfgroup.org]
SALOME is able to handle it well - but any Software based on opencascade should be able to handle it.
It could even store the G-code along additional data.