3D Exchange Standard
12-May-95 03:02:12
Sb: #11651-3D Exchange Standard
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