mp1u+@andrew.cmu.edu.UUCP (11/29/87)
With all the talk about interchange programs between Videoscape 3D, Sculpt 3D, Forms in Flight, etc etc. I begin to wonder why an IFF format for describing three-dimensional objects has not surfaced. After all, isn't the whole intention of IFF to avoid kldugy conversion programs and allow various packages to work in tandem? It wouldn't be hard at all to adopt such a standard. Everybody need only offer IFF capability with the next release of their package, with backwards compatability for the old format. Michael Portuesi / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "little things remind me of you...cheap cologne and that damn song too!" --The Flirts, "Jukebox"
page@ulowell.cs.ulowell.edu (Bob Page) (11/30/87)
mp1u+@andrew.cmu.edu (Michael Portuesi) wrote:
>format for describing three-dimensional objects has not surfaced.
I asked Harriet Tolly (of Syndesis, the people who have Interchange)
why they didn't publish their internal format as an IFF 3D spec. She
said their format is "memory based" and contains all kinds of hairy
graphs, trees, networks, linked lists, etc, all interconnected in
funny ways, and trying to describe it in a text file would be really
hard.
I don't know how much I believe this (they have to define C structures
in Interchange, right?); I suspect the real reason is they want to
make a buck out of the lack of 3D standards. I don't blame them, but
I think somebody is eventually going to come up with a IFF 3d format.
She also mentioned some new avenues for Interchange; they wanted it to
be more than a format converter, and were thinking about having it do
some manipulations the 3D packages don't do now. I didn't get the
whole gist of the idea, but something like: Now, you have a Sculpt-3D
file, want to do something to it that Sculpt doesn't let you do, so
you convert it to Videoscape format, change it, then convert it back
to Sculpt format. With the "new and improved" Interchange, you'd just
say "do this transformation to this file" and it gets done without
having to convert it many times.
Anyway, that was just my impression; I may have totally misunderstood
what she was talking about. She *did* say they wanted Interchange to
be more than a converter, but didn't commit to anything.
BIX is discussing IFF formats and standards in amiga.dev/iff -- where
most of the developers are, and probably where any decisions get made,
so if you're really interested in IFF standards, you should put in
your 2c over there.
..Bob
--
Bob Page, U of Lowell CS Dept. page@ulowell.edu ulowell!page
"I've never liked reality all that much, but I haven't found a
better solution." --Dave Haynie, Commodore-Amigaewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (12/01/87)
In article <4VfpM8y00WAKzW005j@andrew.cmu.edu> mp1u+@andrew.cmu.edu (Michael Portuesi) writes: >With all the talk about interchange programs between Videoscape 3D, >Sculpt 3D, Forms in Flight, etc etc. I begin to wonder why an IFF >format for describing three-dimensional objects has not surfaced. >After all, isn't the whole intention of IFF to avoid kldugy >conversion programs and allow various packages to work in tandem? > Yup. However, a general specification for a 3D object is inherently more complicated than a spec for a bitmap image. The idea behind IFF is for it to be as general as possible. 3D objects can contain any number of characteristics, all of which have to be accounted for in the standard. A 3D object is (usually) defined using points and polygons. How are the coordinate triplets stored? IEEE floating point? Some systems have no concept of IEEE. What about each polygon? How do you specify its characteristics? Is it matte? Shiny? Mirror-surface? Transparent? Translucent-diffusive? Luminous? Is this object merely a collection of flat polygons, or is it truly solid (it makes a difference if you're ray- tracing something made out of glass)? What about the points? Do they specify a polygon, or a bicubic surface? Or perhaps they specify something else. How about lighting? Are you using a point source, or directional source? Do lights have color? Finally, how do you format all this information in such a way that it can be read and written easily by more than one system? Remember that some CPU's have different ideas about hi-low byte ordering for words/ longwords, etc. >It wouldn't be hard at all to adopt such a standard. Everybody need >only offer IFF capability with the next release of their package, >with backwards compatability for the old format. > Adopting a standard is easy. Creating one is the tricky part..... Addendum: I'm led to understand that, in fact, a 3D object IFF standard is being hashed out on BIX by Volk & Co. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
keithd@cadovax.UUCP (Keith Doyle) (12/01/87)
References: In article mp1u+@andrew.cmu.edu (Michael Portuesi) writes: >It wouldn't be hard at all to adopt such a standard. Everybody need >only offer IFF capability with the next release of their package, >with backwards compatability for the old format. I wish it were so easy. It would seem the only way to be standard is to encode in ASCII floating point, as there is no standard binary floating point format. Then you have the problem that some packages work with polygons, others only with triangles. There's also the problem that some manufacturers wish to keep their schemes proprietary. You ought to see what a mess the compressed animation standard has been going through. Anyone working on a MOVIE! to IFF ANIM converter? I'd sure like to use one of those right now. And the MOVIE! format may be proprietary. No matter who you talk to, everyone seems to have a different opinion of the value of various animation compression schemes. ("well, it's ok, but mines better!"). There seems to be one way that efforts for standardization MUST proceed for us to get anywhere. The standards must be WELL DOCUMENTED, and WELL DISTRIBUTED. For distribution, start with Commodore. You can't standardize on something if you don't have a supporter who's willing to document and work to get a standard approved. Unfortunately, most developers are so busy trying to out-compete each other, they haven't got time or inclination to worry about standardization. The IFF standards have bought the Amiga a lot of capabilities you don't see with other machines. A lot of programs couldn't exist if it weren't for standard image and sound files. And the standards aren't perfect, IFF images could be compressed better, 8SVX sample files could better support octaves that aren't simply reconstructions of the same sample, etc. True, standards usually mean standardized mediocrity, as the state of the art is changing fast enough to obsolete anything that's been around long enough to be documented. And at times, proprietary solutions are a way for developer to protect his investment in his software package, or protect a future market for his own follow on products that would otherwise be filled by a competitors products. I figure if a developer has to do that, it is a sign that he is insecure with his ability to develop competitive products, and is resorting to a lock-in strategy that will keep you buying his products anyway. Still, he will not be able to keep up with a group of his competitors, if they are banding together with standardization and present a ultimate modular solution to the user that is a synergy of all of their talents. Imagine if you bought a CD music album produced by Sony's new CBS label, that could only be played back on Sony decks. And figuring that Sony has big names under contract such as Springsteen, Michael Jackson etc., we could all be buying Sony decks if we want to listen to such music. A&M could team up with some other CD manufacturer, and we'd all end up with 15 different decks to be able to listen to the music we want to hear. And jeez, we have a big market for DAT decks that allow us to convert to a common format. If we're a DAT manufacturer, we're seeing dollar signs. If we stuck only with Sony, we'd only have Sony's music choices, and with only A&M we'd only have theirs. Even if we bought both a Sony and an A&M format player, we could listen to both, but we may not be able to create a continuous stack of CD's from both families that we could listen to in a single setting. We've lost a lot of functionality, and it's cost us lots of extra bucks. Standards do buy functionality, and provide for synergy, that can sometimes not be had any other way. One thing that might help, is to keep the idea of standardization in high esteem, and perhaps particularly when reviewing products. We should applaud EA and Aegis for their standardization efforts, if nothing else, and continue to pressure other companies with questions like "what are you doing about standardization". If the answer is "nothing", let them know that you disapprove (assuming you do). It is also important to realize that if everyone stuck to standards, products like Foust's would be unecessary. It would be easy to develop a big market for hundreds of conversion programs if that is how you like to use your Amiga. You developers out there may see gold in the proliferation of non-standard products out there. And if noone makes noise about standards, everyone will be paying $29.95 (or whatever) every time you want to merge data from one application to another. The standardization efforts on the Amiga, to date, have been one of the better "features" of the machine, in my estimation. Let's try to keep from losing that particular feature if possible. Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
haitex@pnet01.cts.com (Wade Bickel) (12/02/87)
mp1u+@andrew.cmu.edu (Michael Portuesi) writes: >With all the talk about interchange programs between Videoscape 3D, >Sculpt 3D, Forms in Flight, etc etc. I begin to wonder why an IFF >format for describing three-dimensional objects has not surfaced. >After all, isn't the whole intention of IFF to avoid kldugy >conversion programs and allow various packages to work in tandem? > >It wouldn't be hard at all to adopt such a standard. Everybody need >only offer IFF capability with the next release of their package, >with backwards compatability for the old format. > > >Michael Portuesi / Carnegie Mellon University >ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas > >"little things remind me of you...cheap cologne and that damn song too!" > --The Flirts, "Jukebox" I've been working with 3-D images and image formats. I think you underestimate the difficulties in creating such a format, but since so many others have responded to this posting and pointed some of these difficulties, I will not do so. Instead, here is my format: OBJECT = RECORD type : CARDINAL; (* EASIER THAN USING SETS *) DATA : POINTER TO LIST OF DATA; CODE : POINTER TO RENDERING ALGORITHM; ORIENTATION_DATA : DESCRIBES OBJECT'S POSITION AND ORIENTATION; LINK : USED TO "CONNECT" OBJECTS; END; In this way, each object can utilize a custom rendering algorithm. This is very important, as the nature of the image often allows significant shortcuts to be taken. I am not in favor of any format for the point/triangle/polygon data, or for there to be multiple formats. I would not want to be contrained to using floating point data, so the format must recognize a variety of data types. This format works well for me. Obviously its fairly un-developed. Any comments/suggestions will be greatly appreciated. Thanks, Wade. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM
john13@garfield.UUCP (12/03/87)
>In article <4VfpM8y00WAKzW005j@andrew.cmu.edu> mp1u+@andrew.cmu.edu (Michael Portuesi) writes: >>With all the talk about interchange programs between Videoscape 3D, >>Sculpt 3D, Forms in Flight, etc etc. I begin to wonder why an IFF >>format for describing three-dimensional objects has not surfaced. >>After all, isn't the whole intention of IFF to avoid kldugy >>conversion programs and allow various packages to work in tandem? > [Leo Schwab gives examples of the many considerations for such a standard] I'm under the impression that any IFF forms you don't understand, or your program isn't concerned with, you can ignore. I'm surprised that more use hasn't been made of this... if 'twas me designing the format for an image or other file, I'd let you put a textual description of the file as an IFF form inside it (maybe even a description of the fine details of the file format); as an option, perhaps encode the same information in two different ways -- as normal IFF, and maybe as specs for a 16 million colour image. An IFF reader would still only read the forms it knew and display it properly. Sure it would be very space-consuming, but you'd only use these options where you wanted to provide extra info/compatibility for another package or person. That's why I hope that whatever standard is agreed upon, will let Sculpt encode more information about, say, palette than Videoscape does, and Videoscape encode more information about, I don't know, complex polygonal shapes; all that's common to the features of the two programs would be available to either, without having an IFF standard for 3D that conformed to the "lowest common denominator" (I'm thinking of awful graphics printouts right now and shuddering :-). John -- "A Chinese soldier in Tibet who tried to tear off a British woman's Sergeant Bilko T-shirt has become the first known case of someone mistaking Phil Silvers for the Dalai Lama." -- Toronto Globe & Mail, Nov. 14/87
peter@sugar.UUCP (Peter da Silva) (12/03/87)
Any 3d IFF format should at least support objects that are not polygons. For ray tracing, for instance, by far the best format to store a sphere is a center and radius. One of the reasons so many ray traced pictures use spheres (and spheroids) is because it's easy. I was terribly disappointed to learn that Sculpt-3d didn't support spheres as atomic objects. Instead of one of the easiest objects to trace, they're now among the hardest. Pretty strange, considering Eric Graham's original juggler was entirely built from spheres. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
hull@hao.ucar.edu (Howard Hull) (12/06/87)
In article <1215@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes: > Any 3d IFF format should at least support objects that are not polygons. "At least" is hardly a strong enough objection. A mathematical function is something a computer should find rather straightforward to manage. Perhaps it takes a lot of cycles to render some of them, but I wouldn't want to find, for instance, that the Mandelbrot set was _excluded_ as a terrain-like object. > > I was terribly disappointed to learn that Sculpt-3d didn't support spheres > as atomic objects. Instead of one of the easiest objects to trace, they're > now among the hardest. Pretty strange, considering Eric Graham's original > juggler was entirely built from spheres. With 68020s and 68881s becoming more and more prevalent in single-user computers, some things that were outrageously slow a few years ago are now within tolerable limits. Tomorrow it will be even better... > -- > -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter > -- Disclaimer: These U aren't mere opinions... these are *values*. Howard Hull "Scientific American October 1987 - "The next revolution in computers, the subject of this issue, will see power increase tenfold in 10 years while networks and advanced interfaces transform computing into a universal intellectual utility." Remember, IFF is an interface!