CompuServe Messages

3D Exchange Standard

    12-May-95 03:02:12
Fm: Tim Wilson [Crestline] 76432,1122
To: Syndesis 76004,1763
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