3D Exchange Standard
15 messages in this thread
Hi Tim,
Good topic. I don't have the full picture by any means, but can add a bit here
and there, broken out by format:
DXF: Yup, go bye-bye, please. Better than nothing, but everyone who's used more
than one tool must know its drawbacks by now.
RIB: This was designed as a rendering-level scene description language. The
underlying architecture can support animation, and it has particularly good
support for hierarchies, surfaces, lights, cameras, higher-order geometry, and
more.
RIB export varies among tools, however… the limiting factor is the
underlying geometry database. I haven't come across any tools other than
Pixar's on Mac, Win or DOS which import RIB… few on NeXT, but that platform's
waned terribly.
RIB's well-documented in "The RenderMan Companion" [Addison-Wesley] and the
RIB Specification (available through Pixar).
OpenGL: Flexible, but implementations to date have not been widely used. NT
support helps, but seems to require acceleration on Intel-based chips. Am not
sure if it's in Win95.
VRML is an important offshoot of OpenGL, via Inventor. I haven't picked up
docs on this yet, but it seems to have momentum. Anyone have details on this?
OpenGL's well-documented in the Addison-Wesley books.
3DMF: Although the 3D Metafile format of Apple's QuickDraw 3D won't be
practical until it's in v1.0 release later this year, it also seems to have
momentum. Like QuickTime it will go multiplatform in the rev after initial
release. From what I've picked up it's got support for higher-order geometry,
surfaces, lights, cameras. Am not sure about time-based information. Because of
the volume of machines out there and because of Apple's reputation for quality
I'd guess this has a real good shot at being an effective standard.
(All the above's my personal take on things, and in no way represents any
official Macromedia position, btw.)
There's another way of looking at it besides formats, too… that's in terms of
libraries. Although 3DMF is a format, the underlying QD3D is an API that can be
supported by both software and hardware. I haven't heard word yet on what
Microsoft will be doing with the RenderMorphics libraries, but would expect
something similar. Besides the file formats themselves, it's the whole context
of software and hardware support which will determine which formats become most
prevalent.
Have you read that recent article on the componentization of 3D software…
think it was in the latest CGW? Touches on themes similar to your post, Tim.
Interesting topic….
Regards,
John Dowdell
Macromedia Tech Support
>> Interesting topic…. Regards, John Dowdell Macromedia Tech Support
John, along with this, What's up with smart 3D?
Alan
Hi Alan,
It's reached the point where I can't say much. <g> It's taken longer to get
started than I had hoped, but has had the advantage of being able to be
replanned around new developments, and is now exploiting a richer vein than I
had previously thought possible.
As you know, Oracle has licensed Smart3D for inclusion as an Oracle Media
Object in their video-server authoring environment. Development's under way…
no release date yet. The "Freeze Tag" demo is cool, but I've played it enough
already… I'm waitin' for the real thing! <g>
Regards,
John Dowdell
Macromedia Tech Support
John,
Thanks for filling in some of the pieces. I talked with Bill Allen at
3D Artist and he helped to clarify a few more things.
>> it's the whole context of software and hardware support which will determine
which formats become most prevalent.<<
Agreed, however, one of my questions is whether it would be
worth while to start a more grass roots approach to developing a new
3D exchange standard, through some user advocacy group like the 3D
Art Forum, or simply wait to see what the major players in the 3D
market come up with.
From what I can see at this point, a couple important issues
could determine the fate of the commercial formats and their future
popularity. For example, if VRML is adopted as the standard format
for the World Wide Web VR interface, this could make it a very
prominent and popular format.
And of course whatever MicroSoft decides to do could have a
pervasive impact. But so far they apparently haven't made a
definitive move towards one standard. It appears they could go in
several directions. As you said, VRML is an offshoot of OpenGL. If
VRML works independent of OpenGL this might be a possibility, but
exchange formats that would _require_ OpenGL look doomed for the PC
at this point because OpenGL's hardware requirements are too extreme.
MicroSoft still has several other directions it could go. They could
promote a new format based on SoftImage, Reality Lab, or its possible
they might be content to pick up on the MAC's 3D Metafile format from
Quickdraw3D if it proves popular.
Bill Allen indicated that MicroSoft is trying to come up with
a standard for motion files and this might be part of what's causing
them to delay committing to a standard.
Keystone (SGI's other direction) appears so nebulous at this
point that it's probably not worth discussing.
Do you think VRML could be used with systems or programs
without OpenGL? If 3DMF supported motion do you think it would make a
suitable standard for Macromedia, and other 3D devs/users, for that
matter?
My suspicion is that all these formats will garner a certain
following, and we'll end up having to convert between them all. But
at this point 3DMF looks like it's got a head start on all the rest.
If RIB is such a good standard I don't see why it isn't given more
consideration. The only thing I can figure is that others devs of
rendering engines didn't want to give any support to their
competition, RenderMan.
>>Have you read that recent article on the componentization of 3D
software… think it was in the latest CGW.<<
Yes, “Untamed Animation'' in the April CGW was part of the
genesis of this discussion. The article mentions the problems and
proposed `solutions' to interoperability, but its explanation of how
these new standards work was too watered down to be useful. I suspect
CGW is cautious about showing a bias towards any of these.
-Tim
Yes, you can parse and display VRML without OpenGL. As I pointed out in my
first posting, Apple plans to release a Windows version of QuickDraw 3D for
Windows approximately six to eight months after the release on the Power Mac
later this summer. That's next summer at best.
Hi Tim,
Glad you pulled Bill Allen in on this… the magazine's a great resource. And
nobody's done more work with file formats than John Foust… cool.
There are VRML docs on the web… believe it's through SGI's home page… but I
haven't hit them yet. Suspect it would be structured similarly to OpenGL but I
know next-to-nothing of practical use here yet.
Will Macromedia read/write 3DMF? Odds are strong, but there's no formal
announcement of future tools yet. When Escher (code name for QD3D) debuted
there was a list of companies which would "support" it, but the nature of that
support was rather on the nebulous side. <g> Seems to be three levels of
possible support: read/write of 3DMF format; utilization of system-level
rendering (restricted to PowerMacs in initial release); and deeper use of the
QD3D API. Until the rubber meets the road, the file format itself is pretty
much what anyone can reliably work on today.
RIB's a great format, but I'm not surprised most tools don't read it. For one
thing, desktop 3D apps largely are unable to make heads or tails of
higher-order geometry. Look at the market — the majority of affordable tools
are restricted to polygons. RenderMan was designed to work fastest with
spline-based datasets. Most desktop 3D apps would be incapable of reading the
standard RMan geometry definitions.
The reason most developers cite for not importing RIB is the surface
definitions. Again, current desktop technology is the limiting factor: texture
maps (invented by the president of Pixar, btw) rule the roost, and the few
procedural surface apps don't support the variety of function calls found in
the RenderMan Shading Language. Between geometry and surfaces, I'm not
surprised that DXF is the lingua franca and RIB is reserved for export, if
that.
Something I was thinking of when writing the last post — but didn't include
for fear of going off-topic — is similar to the above RIB/DXF format
comparison, except it's in the realm of plug-ins. Example: Macromedia's
FreeHand 5.0 reads and writes Adobe Illustrator plug-ins as a subset of its own
native plug-in format. Illustrator's plug-ins are modal — they'll bring up a
dialog, you do your work, then later see the results upon the page.
FreeHand's plug-in format is non-modal… you can interactively draw on the
page while using the plug-in… in fact, you can even have these plug-ins drop
into FreeHand's own tool palettes, like a VBX would. The FreeHand plug-in
format is richer.
But… which will third-party developers go for? The pressure will be to market
in the least-common denominator format, for widest possible market share. Some
will take advantage of the advanced features in the higher-level format, but
it's the DXF/RIB issue all over again.
What does this mean for the 3D plug-in development community? Will the
least-common denominator rule here too… will plug-ins be hobbled by the
desire to reach the largest number of animators? (Rhetorical question I know,
but…. 😉
Regards,
John Dowdell
Macromedia Tech Support
PS: Just read through the rest of the thread… synchronicity w/Syndesis! <g>
John,
>>The pressure will be to market in the least-common denominator format, for
widest possible market share.<<
That's not what's happening right now, at all. Add-ons are coming out
in abundance for 3D Studio, and virtually nothing else.
Users of other programs like Imagine, Animation Master, TrueSpace,
Topaz, Strata, Inifini-D, Macromedia and other popular 3D rendering/animation
programs are getting practically NO NEW 3D UTILITIES AT ALL, because IPAS
routines only work with 3D Studio. And as you might guess, users of these other
applications aren't exactly pleased by this turn of events.
That's why I'm against the idea of plug-ins. Because it deprives many
3D artists access to new tools, and it's being used by companies like Autodesk
and New Tek as a tool of exclusion. If this is what they mean by “open
architecture'' then I'm not in favor of it.
If IPAS developers were writing all their programs as standalones that
output a standard file format, then practically any 3D artist could use their
products,… and they'd probably be making a lot more dough as well.
But without a more sophisticated 3D exchange standard this is basically
impossible. And companies like Crestline and other 3rd party developers will
have to go on creating a different package to go with each rendering program.
We'll have to design a plug-in for 3D Studio, a plug-in for Lightwave,
a plug-in for Imagine, etc, etc…. And we'll end up spending all of our time
doing ports to different packages, instead of concentrating on new projects.
I guess I didn't make my views on this clear earlier. I hope this helps
you to understand better where I'm coming from. To give you one last concrete
example: without a better 3D standard I doubt you'll be seeing any Humanoids or
KineModelz to work with MacroMedia products. That's bad for you and bad for me.
I'd like your users to have access to my models. If I have to resort to using
the DXF format, they aren't going to be nearly as good.
Now, if you're proposing some type of “STANDARD plug-in technology'',
which could work with ALL 3D programs, THAT might be an idea I can get behind!
Because it would save me a heck of a lot of work. I guess that's what
OpenInventor is all about.
>>What does this mean for the 3D plug-in development community? Will the
least-common denominator rule here too… will plug-ins be hobbled by the
desire to reach the largest number of animators? <<
I've already explained why I think a new 3D exchange standard is
preferable to plug-ins. If a _slight_ loss in facility is necessary to allow
more 3D users to have access to our products, then so be it.
But I don't think a 3D standard necessarily has to be the lowest common
denominator. A good standard can support very complex features, but not all
devs have to make use of them.
(switching gears slightly..).
>>>Most desktop 3D apps would be incapable of reading the standard RenderMan
geometry definitions… The reason most developers cite for not importing RIB
is the surface definitions. Again, current desktop technology is the limiting
factor: texture maps (invented by the president of Pixar, btw) rule the roost,
and the few procedural surface apps don't support the variety of function calls
found in the RenderMan Shading Language.<<
So then it's Pixar's fault that their RenderMan format wasn't adopted
as the standard, because they didn't design it to be downwardly compatible with
simpler 3D applications.
Again, I don't see any reason why a good 3D standard can't be designed
to handle both complex and simpler data transfer effectively.
-Tim
Hi Tim,
True, what you mention about those listed tools not having third-party plug-in
developers. Then again, the only published API in that list that I'm aware of
is from Specular, and no one (to my knowledge) has taken them up on it. This
seems to be the limiting factor… can't plug into an app if there's currently
no SDK for it! <g>
This seems natural to me… new technologies are first spearheaded, and only
then have a wider impact. Has to start somewhere. The pressure is certainly on
plug-in developers to get a wider possible market than any one 3D tool can
offer… this is incontrovertible. And this next year will be interesting, when
DOS and Phar Lap are left behind and PC development is forced to move to 32-bit
Windows….
I hear what you're saying, though… porting to different APIs is expensive,
and it would be more pleasant if there were a standard exchange format. An
exchange format and discrete apps would disable callbacks to the host, however,
and that's a *big* disadvantage compared to plug-ins. fwiw, most 3D APIs I've
seen have a great deal of functional similarity. I'm hopeful for the future.
Not sure I understand your next-to-last paragraph — the failure of texture
maps is exactly the same failure of polygon-based modelers, and that's
resolution-dependence. Procedural textures and parametric surfaces are
resolution-independent and also offer additional flexibilities. If other apps
only offer the ability to texture through bitmaps, well, that's their problem.
It's sort of like, should NewTek be faulted for supporting general polygons,
because 3D Studio can only handle triangles? RIB can describe polygon lists,
but most tools that write RIB default to exporting at the advantageous
patchmesh level instead… tools which can only read polylists will be at a
disadvantage in RIB, unlike in the least-common denominator format of DXF where
everyone is forced to a common ground.
Even if we had a more robust common 3D exchange format we'd still have the same
problem, even for just geometry: at what level should shapes be described? If a
poly-based tool received a NURBs-based file, would it be the receiving app's
responsibility to reinterpret this geometry? Or should it be the exporting
app's responsibility to include multiple representations of the same geometry?
("Yikes!" to file size!)
The RIB spec includes a header line for "Capabilities needed"… this is where
optional features, such as procedural surfaces or stochastic motion blur, are
listed for quick preview. If a receiving renderer cannot support, say,
pixel-based displacement, it should ideally degrade gracefully and just not use
that part of the file, while still accepting the features it can support.
Anyway, knotty issues, good conversation! <g> I'll bring these sentiments back
to the gang at the office, thanks!
Regards,
John Dowdell
Macromedia Tech Support
What spec has Specular defined?
I think your assessment of the least-common-denominator is a good one. Unless
the new standard includes code for an absolutely robust and portable polygon
tesselator, any triangle-based program will avoid the polygon-based standard.
And then there's procedural textures, bitmap textures, etc. And then there's
CSG and NURBs.
We encountered this in InterChange when we considered the Real 3D file format.
Yes, they document it, although the file format seemed to change with every
minor release. It included CSG obejcts as well as Boolean operations between
them, as well as polygons and splines. So we could relatively easily export a
Real 3D object composed of only polygons – except every beta tester we talked
to said that they avoided polygons because Real 3D's renderer wasn't optimized
for them. And when we examined the conversion of Real 3D models to other
formats, overlooking the CSG and Boolean nightmares, even if we tesselated
their splines and patches into polygons, the polygon-count goes through the
roof – easily tens of thousands of triangles for simple objects.
So, speaking of documenting file formats, we do have code in-house for the old
3DGF format. If I remember correctly, we stalled because we couldn't get the
documentation for your scene file format that linked together all the separate
3DGF files. At one point, Macromedia techs were recommending that we call
Knowledge Revolution, who had reverse-engineered the scene file format. What's
new in the world of Macromedia, and how can we improve the support for your
company's products in InterChange? 🙂
Hi John,
I recall picking up a kit for Specular's Animation Assistants on their AOL
forum. Their included plug-ins include a banking one (roll varies with yaw),
and two others I forget. From what I recall it was limited to motion… no
geometry, camera, or compositing effects.
Yikes on that R3D conversion to other formats… yes, what should be done with
something like CSG? Many tools these days can do trim surfaces, but subtracting
one shape from another while both are moving? That's Barfland for universal
access.
Nothing much has changed in the 3DGF format introduced with Macromedia Three-D
in 1991. The format's still in the library over in MACROM… geometry-based
derivative of RIB, as you know. Right now we're "between tools", and here are
Macromedia's various native 3D formats:
— 3DGF docs are there… Ray Dream, Working Knowledge picked up on that
format, but few others… 3DGF has stuff in the Mac resource fork, so it's
platform-dependent.
— 3DWorks: Still (imho) a very nice text animation format… no specific docs
on it, but easily doped out by inspection.
— LifeForms is only licensed for distribution by Macromedia, and we don't own
the source code so can't move forward on it. Puts out motion scripts in 3DW and
Swivel Command Script format, as well as Electric Image 1.0 format, but its
native file format isn't of much use to other applications.
— The Swivel format is a snap, but it's of limited usefulness… pathform
polygons, and limited to Macs.
–The MacroModel reader files are still available through Rix Kramlich, 3D
Product Manager. Geometry's described as spline pathform, Bezier patchmesh, and
polymesh. Most apps can't display the first two, so polymesh would likely be
the exchange format… that means few advantages over DXF.
There will be some changes in the near future, but that's all I've got today!
Regards,
John Dowdell
Macromedia Tech Support
Actually, Swivel is a real bear of a format. It's inane. At the lowest
levels, it still bears traces of its origin in Forth, such as storing X, Y, and
Z in one place, and Z, Y, X in another. Since all of the Swivel data is in the
resource fork, we have already developing a library of portable subroutines for
reading them, so I'm not afraid of handing the resource fork side of
MacroModel.
As for the 3DWorks animation format, please, if you ever get a spare moment,
"easily inspect" the files and tell me what everything means. 🙂 With that,
we'll be able to read and write entire scenes, instead of just 3DGF.
We did use that MacroModel source code from Rix as a starting point, of course.
But that code is another example of the sorts of program-specific 3D data that
makes a least-common-denominator standard difficult… few programs have
those same concepts. There's a landscape-like data grid object type in there
too, isn't there?
[Sorry for delay… found this in my outbox when I got back from vacation last
week.]
Hi John,
There's no resource fork to a MacroModel file… it's designed so the same file
can be worked with on either platform.
For 3DW, there's the header (refers mostly to location of geometry), the tail
(describes where the playback head is in the Score, selected cells and stuff),
and the body (combination of keyframes and traits for specific objects). There
are a number of extra arguments for spline interpolation and reserved words,
but those are minor frequency… main elements are quickly discerned, even
though it's not documented. But to what use would you put it?
Yes, true, a Bezier mesh is uncommon today. The Working Plane is a geometry
aid, not a piece of a model that would be exported.
Next message: Swivel itself hasn't changed since 1990 or so, when work started
on the Paracomp Modeling (PMDL) engine that became MacroModel. I don't know of
any differences in it over the years… Specular, Ray Dream and Adobe run it,
and I'm sure others do as well.
Regards,
John Dowdell
Macromedia Tech Support
If we could create those scripts that link together 3DGF files, then we can
read/write entire scenes, as opposed to single objects…. Yes, the 3DWorks
documents are ASCII and could be easily parsed or generated… but just open
up, oh, "1) Chef Tumble" and tell me what each and every little number is, and
I'll be on my way. 🙂
What is the latest version of Swivel? Does it have a forwards- or backwards
compatibility problem when it comes to geometry? E.g., can you save a model
from 2.0 and load it into 1.52? If not, what changed in the file format?
Hi John,
Actually, Swivel 1.52 was _long_ before my time… I came in as a 2.0-boy about
four years back. Version 2.04 was released in… oh… April '93? as a
maintenance release for 68040 machines. I'd be surprised if the basic format
has changed much… I know that 1.x files still open up in a variety of tools
that read Swivel 2.x format.
Regards,
John Dowdell
Macromedia Tech Support
Also, what's the latest Swivel file spec? Young sent us the 1.5.73 spec, but I
know there's a 2.0 format and we've never been able to get the docs for it.
Gee, I guess you're glad you jumped into this discussion so I could chastise
you about file formats, and hold you up as an example. 🙂 Would you like to
see a beta copy of InterChange for Windows? At least that would give you a
chance to take me to task, too.