CompuServe Thread

3D Exchange Standard

5 messages in this thread
#11504From: Tim Wilson [Crestline]May 6, 1995 4:02 AM
John, Since there is no serious discussion that I'm aware of by the major players in the 3D market for extending the DXF format, I had put my focus on the newer formats. Perhaps you're onto something here though. A new DXF format might be possible to promote on a grassroots level, but it would take a lot of work to twist all the 3D devs arms into supporting it. Again, I come back to my main concern. That is, the ability to link different 3D apps, or at least generate files with greater mobility from things like 3D Paint programs, Spline modelers, Metaball modelers, Procedural Animation programs etc., so devs of these apps can make their products standalone rather than plug-ins, and usable by a broader base. Would an enhanced DXF or OBJ be more suited to this job than some of the new-fangled API formats? Based on what I've heard lately, by next year we'll end up with a couple of popular enhanced formats: VRML, 3D Metafile, and something from Microsoft; and perhaps some revised object formats: DXF, OBJ, RIB (and 3DS?). I doubt that OpenGL and Keystone will make it into the mainstream, and I don't fully understand where OpenInventor will fit into this scheme. -Tim
#11515From: SyndesisMay 6, 1995 11:02 AM
Yes, I think it would be easy to promote some conformal comments for DXF and/or Wavefront. It's something that could be slipped in by a programmer without management approval. 🙂 Just give the standard extentions a name "DXF Enhanced" for example, something to put on a checkbox in a dialog. You could also merely standardize the way the concept of polygon should be represented in DXF. Believe it or not, there is little agreement about this, which explains why DXF is a poor or at least unreliable method of moving 3D data between programs.
#11642From: Tim Wilson [Crestline]May 8, 1995 4:32 AM
John, >>…You could also merely standardize the way the concept of polygon should be represented in DXF. Believe it or not, there is little agreement about this, which explains why DXF is a poor or at least unreliable method of moving 3D data between programs.<< After giving this some further thought, I'm afraid I'll have to agree with other folks here, that it's time the DXF format went the way of the Dodo. Send it packing. Put it out to pasture. Retire it. I just don't think it's up to handling the complex new features that I and other 3rd party devs will be looking for in a good exchange standard. And there's already so much DXF stuff out in the public domain that compatibility problems will probably just worsten. Undoubtedly many devs will want to continue supporting it just for loading models. And that's fine. But a different format with clearcut specs is needed for the next generation of 3D utilities coming down the pike, one which is freely licenseable, and fairly easy to implement, like you said. Right now I'd put my money on 3DMF, or OpenInventor/VRML. RIB looks like a dead-end because of the lack of downward compatibility. OBJ doesn't have much more going for it than DXF, except that there are less variations, I quess. >>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.<< This is extremely narrow-minded, and I'd be glad to see such CEO's go the way of DXF, and the Dodo as well. In any case, if a good standard emerges, pressure from users should turn this around. -Tim
#11651From: SyndesisMay 8, 1995 9:23 AM
What DXF and Wavefront have "going for them" is that they're allready whoops already supported in many programs. It's going to be a year at least before any new format is securely added to enough 3D programs to make it a significant force. So exactly what is the minimum you want in this new format?
#11926From: Tim Wilson [Crestline]May 12, 1995 3:02 AM
John, >>>What DXF and Wavefront have "going for them" is that they're already supported in many programs.<<< Perhaps my anti-DXF remarks were a bit extreme. Modifying an existing format might work, but intuitively, I just feel like a breath of fresh air is needed. There's alot of junk in the DXF format that isn't essential to most 3D animation packages, and combining alot of new parameters with this already existing complexity would IMO make things overly confusing. For this reason I don't think DXF would make a very good foundation on which to build. I don' know much about OBJ. But as I've said before, I think a crisp, clean, trim, new format is needed, with clear cut specs. I still haven't figured out whether a new `grass-roots' user standard would be preferable to one of the new commercial 3D formats already in the pipeline. But I'm tempted to go with one of the commercial ones, because developing a new user standard, and building the necessary support for it would take alot of work. In addition, I doubt a new standard would have much chance without the backing of a major player like Apple or MicroSoft, or some influential advocacy group like SIGGRAPH/ACM. But who knows, once the ball gets rolling, it might take off… But I agree with many of your other comments about what's necessary to make a new standard workable: easy to implement, no licensing fees, etc. >>> It's going to be a year at least before any new format is securely added to enough 3D programs to make it a significant force…<<< I doubt that only one single format will predominate in future. Several will probably emerge as strong forces. But I think we'll _need_ about a year to sort all this stuff out. Personally, I'm not looking for a quick fix. If it'll mean a more solid format in the end, I don't mind waiting. >>>So exactly what is the minimum you want in this new format?<<< Ideally, the format should be able to handle all the basic elements contained in a 3D scene, including models, textures, lights, motion, object and vertice-based (morphing) transformations, hierarchies, etc, and any combination or subset thereof. It should be suitable for linking physical dynamics generators, 3D paint systems, articulated models (naturally), and other IPAS-like animation and modeling packages with a variety of 3D rendering/animation packages. The standard does not have to handle all the complex procedures internally, it just needs to be able to translate the end result from one place to another. For example, a physical dynamics package would only have to export a series of transformations, and possibly some deformation or morphing info, simple enough to be handled by even basic rendering packages. The standard doesn't necessarily have to handle complex procedures like gravity, viscosity, collision detection, etc. because these can be broken down into basic transformations, that almost any 3D animation package can understand. A 3D Paint system probably should be able to export image maps and geometry (of course), surface properties, mapping types, mapping coordinates, surface subgroups. Again, most programs can readily support these basic elements. To transfer articulated models, the format should contain the geometry, hierarchical links, pivot points for bones or separate objects, and some type of surface subgroups or area of influence for bones. In addition the standard should support keyframes or different poses, probably through transformations (usually rotation) of the joints or bones. And it should handle 3D morph targets in some way as well, either as separate meshes, or transformations of points. The standard should also allow as much crossover as possible between spline and polygon packages. For the time being it may only be feasible to effectively take geometry from splines to-> polys, but eventually I can envision the standard incorporating a translation menu which asks the user a couple simple questions about how to rebuild a poly mesh into splines, i. e. 1. Convert polys to patches on a 1 to 1 basis? or 2. Generate new optimal spline mesh? If you chose option 2, then enter value for new spline mesh complexity,… You get the idea. For other ideas on mesh processing you might want to check out the “Smoothing Utility'' and “Alf's Wish List'' threads in the ANVENA – IMPULSE section. I and others have sent a lot of suggestions to Alfonso Hermida on this subject, including some on spline to poly conversion. I know that there are variations in the way most 3D programs handle these functions now. However, a standard such as the one outlined above would solve many of the problems faced now in crossing over all such info directly from one program to another. A sophisticated standard would act like a buffer, making it easier to move more complex information around. All developers would have to do is conform one of their output formats to the specs of the new standard. They can continue to have as much complexity as they want internally and have their own proprietary formats handle 3D properties exactly the way they want. All they would need to do is have an internal translator that would crossover some of their proprietary features to the new standard. And it would be entirely up to the developers how much complexity they would import/export from the new standard. -Tim