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
    __@/