CompuServe Thread

Tim tipped me off to the existence of this thread, so I'll jump in with both feet! My company makes InterChange, a program that translates between more than thirty 3D file formats, so I've got a special perspective on this topic. I'll start with a comparison. Consider all the bitmap image file formats. Bitmap data is more simple in structure than 3D data. I can describe what's stored in image file formats in just a few sentences! Yet there are dozens of image file formats in use today. Serious image processing programs must handle a dozen of them, and I know of more than a dozen companies that specialize in making file filters. Why so many image formats? Some are merely historically popular, some are more popular on one platform than another, some serve special purposes like JPEG and FAX. There's no real standard in the 2D structured drawing market, either. CGM, Windows metafile, Adobe Illustrator, Freehand, Corel, and a dozen other presentation graphics programs are all distinct formats, and clip art companies are forced to support more than one. 3D data is more complex than bitmap data. Even with a minor subset like basic geometry, it's tough to find common ground between today's most popular 3D programs. (For the moment, let's put aside splines and patches, motions, bones, cameras, lighting, hierarchies, particles, etc.) Some use only triangles, others allow polygons with an indefinite number of sides, others allow "point" and "line" polygons with just one or two sides. Then there's surface attributes. Again, there is little common ground once you get past basic RGB color, specularity, etc. For example, smoothing is handled differently in every package I've examined. Some rely on underlying geometry like shared points and edges to define smoothing, others have smoothing groups, others have explicit or implicit shading angles, others allow more control. Tim, I'm sure you encountered these differences when porting your humanoids from program to program. A standard is as likely to offend as please. If the standard includes concepts that aren't possible in a program, I'll bet the designers will decide not to support the file format, because it makes their program look inferior. A file format often reflects the design decisions of the programmer. If a file format reflects different design decisions than those in a program, it's been my experience that the programmer and the CEO of that company are less likely to consider supporting that format. This is true for proposed "standards" as well as any other file format. For example, you mentioned the support for DXF in Animation Master. It's very difficult for them to import any polygonal format, much less the most difficult yet most popular polygonal format, because their models are naturally built from splines and patches, not polygons. Do you think they'll support a polygonal standard? Similarly, not a day goes by when a customer doesn't beg for a polygonal program to support spline patches. If the standard includes spline patches, will purely polygonal programs want to support it? A standard file format must reflect a least common denominator. In that sense, the much-maligned DXF format meets this criteria. It's so basic it doesn't even include surface color info. (Also, the latest R13 DXF includes encrypted, un-documented CSG geometry.) A standard must be easy to implement. I recommend that the promoters of the new standard should hand out portable ANSI C source code for importing and exporting the file format. On this "easy to handle" criteria, DXF is an awful format. It is very difficult to read properly, which leads to the incompatibilities we've all seen. It is a CAD format that's been pressed into service to represent polygons. Even if the code for parsing the file is available, you must remember that companies must support it in the expanded sense of the word. They'll need to deal with incompatibility problems when customers share files with everyone else's implementation of the standard. They'll need to write additional code to insure that the data they read or write conforms to the standard. In the future, they'll need to preserve compatibility with it where possible. All this means extra effort, above and beyond what they're doing now. Just because the new standard exists, doesn't mean that the demand for DXF support will diminish soon. Believe it or not, I've even heard from some CEOs who balk at supporting any other file format. They regard their 3D program as the best, and they regard support for other company's formats as "aid to the enemy." They regard universal file formats as a way to make it easy for customers to flee their 3D program and purchase other 3D programs. It doesn't surprise me that commercial modeling companies most frequently complain about the multiple standards. They're the ones most often affected by this. On the other hand, this is the business you've chosen. Tim, you're worried about three file formats? We support more than thirty file formats in InterChange. 🙂 There is no shortage of proposed standards. Viewpoint DataLabs once announced their plans to define and promote the "VIP" standard file format, but no one has ever seen it. Silicon Graphics is promoting the Open Inventor file format as a standard, and a subset of Inventor is VRML, which is the top contender for a 3D file format standard for the World Wide Web. Apple proposed QuickDraw 3D's metafile as an exchange format, except the PC version is expected to arrive six to nine months after the release on the Power PC Macs later this summer. (There are no plans for a 680×0 Mac version, BTW.) I'll also play devil's advocate for a moment. "No wonder he's not optimistic about a 3D standard," you might think, "he's in the business of writing translators." Actually, we take a neutral position, in the same way we don't promote any particular 3D program as the "best." We'll support any proposed 3D standard in InterChange. For example, we worked very hard to be part of the roll-out for Apple's QuickDraw 3D.