Does 3D printing need a new file format? Should Microsoft be the one to provide it?
Those are the questions being asked after Gavin Gear recently blogged about Microsoft's intentions to create a new 3D printing file format. The initiative is to be backed by a consortium of 10 companies, including Hewlett Packard.
I can almost hear the panic in the streets. There is a prevalent fear, particularly among open source fans, that Microsoft will try to find a way to monopolize the industry. The truth is probably a little more logical and a lot less sinister. Microsoft would like to provide something of considerable value to 3D printing users that could help tie the industry to Windows. The problem is, I don't know that a new file format can do that.
Without a doubt, the STL format is too limited for potential future applications. However, STL isn't going anywhere, because it is good enough for the vast majority of today's 3D printers, both professional and personal.
It would be convenient if all 3D modeling software vendors could agree to use one format that handled more advanced techniques such as shading, texture, bump, displacement and normal maps, but that's never happened before and I don't see 3D printing motivating it to happen in the future.
As Lars Brubaker of MatterHackers put it, "Even if the new format is great – and it will probably be great, Microsoft has some very smart people – that doesn't mean everyone will adopt it. When Google came out with a better image format, did that stop people from using GIF, PNG and JPG on their websites?"
Brubaker has a point. There are currently very few printers that can handle the photorealistic color of a texture mapped 3D model. Those that can, accept more file types than just STL. Mcor's Iris accepts STL, OBJ, VRML and Collada. Stratays' Objet500 Connex3 can use STL, OBJDF and SLC. 3D Systems' ProJet x60 series can read STL, VRML, PLY, 3DS, FBX and ZPR. Granted, these aren't all the same file format, but there are convertors to reach these formats from almost any other format available. The conversion process means extra steps, but the 3D industry is used to that, because 3D modelers often have to convert files between software packages whether a 3D printer is involved or not. It's just the nature of the beast.
On the software side, some programs can deal with height map issues before the model is ever sliced. For example, ZBrush is capable of converting a model that uses a displacement map into a high resolution geometry, which can then be exported in a number of formats, including STL.
The point I'm trying to make is that there are methods to compensate for STL's shortcomings now. Combine that with 3D industry inertia and general resistance, and it's hard to imagine Microsoft gaining much leverage in 3D printing with a new file format.
There are, however, other ways Microsoft could become a major player.
Imagine a slicer that looked at the 3D model and changed layer height based on the needs of each area of the model. It would be like a variable bitrate audio codec for 3D printing, except instead of just making the file smaller, it would make the print job faster. Now imagine Microsoft making that slicer an option for Windows and providing an API so 3D modeling software vendors could incorporate it right into the user's 3D modeling package.
While I'm pondering fantasy toys from Microsoft, how about a database and API making it possible to display a 3D printer's build area inside the user's 3D modeling software of choice?
Both ideas have something in common. They would genuinely improve the user's 3D printing experience without putting much burden on the 3D software companies and hardware manufacturers. When Microsoft starts making moves like this, company executives will have something to smile about, because we will all have something to smile about.