Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-lcc!ames!cit-vax!news From: news@cit-vax.Caltech.Edu (Usenet netnews) Newsgroups: comp.graphics Subject: Re: 3d objects posted...Merry Christmas! Message-ID: <1405@cit-vax.Caltech.Edu> Date: Tue, 23-Dec-86 19:58:53 EST Article-I.D.: cit-vax.1405 Posted: Tue Dec 23 19:58:53 1986 Date-Received: Wed, 24-Dec-86 00:15:49 EST References: <6901@decwrl.DEC.COM> <507@elrond.UUCP> <213@mcdsun.UUCP> <10712@sun.uucp> Reply-To: jon@oddhack.UUCP (Jon Leech) Organization: California Institute of Technology Lines: 43 Organization : California Institute of Technology Keywords: From: jon@oddhack.Caltech.Edu (Jon Leech) Path: oddhack!jon In article <10712@sun.uucp> falk@sun.UUCP (Ed Falk) writes: >There's a couple of issues that need to be addressed in computer graphics: >standards for model description and for image storage. Hopefully, they >will evolve on their own before some committee does it. > >I'd like to do a survey. What are the commonly used file formats for >model descriptions and images? I know of the model description format >used at CalTech and the image file format defined in the sun man pages. Actually, we use N different database formats where N is > the number of people in the graphics group writing modeling and rendering software (5 or 6). Sad but true. Our main modeling program has different hooks to spit out the correct format for all the major rendering programs. For image storage, we use two formats: Raster Technology command bytestreams (for practical purposes - just 'cat' them at the frame buffer device), and the Lucasfilm/Pixar format as extended locally for bitmapped images. Neither of these is really adequate for our needs as they stand, but we get along. Part of the problem with image storage standards is that they tend to be dictated by whatever operations are efficient on the hardware the original implementor has handy. This leads to problems as more hardware is acquired. For example, people here used the Rastertech format alot because images went up several times faster than with the program which translated the Pixar format files. Then we got more (non-Rastertech) frame buffers. Unwilling to change their code, people wrote Rastertech emulation programs instead. Trying to come up with standards for this sort of thing is likely to be as successful as convincing everyone to program in the same language. There are wildly different goals and methods of accomplishing them and any design by committee is going to be ignored (at least here). An example is GKS: it's far too complex for what we want to do, it's not clear if it's supported on all our devices, and it costs big bucks in some cases. So it's ignored here. -- Jon Leech (jon@csvax.caltech.edu || ...seismo!cit-vax!jon) Caltech Computer Science Graphics Group __@/