rost@decwrl.DEC.COM (Randi Rost) (12/13/86)
I have posted most of our useful 3D graphics databases to net.sources along with a document that describes the format that they are in. Below is a list of what was posted to net.sources. I have created a library of C routines for reading/writing/creating Object File Format files. This will be released internally at DEC in conjunction with the XModel demo program (in about 2 months). I'm not sure about distributing the sources on the network, but if there is enough demand, perhaps I can twist some upper-management arms to let me do such a thing. I would appreciate sources for any tools that anyone develops to convert or manipulate objects in this format. part1: document and README part2: bottle1 champagne cone cube part3: epcot3 fractal1 fractal2 socbal part4: spring vcube part5: goblet sphere3 vw part6: dart glass5 part7: dart (part 2) dragon part8: glass1 glass2 glass3 mushroom part9: glass4 glass6 part10: x29 sticks
amamaral@elrond.UUCP (Alan Amaral) (12/16/86)
In article <6901@decwrl.DEC.COM>, rost@decwrl.DEC.COM (Randi Rost) writes: > > > I have posted most of our useful 3D graphics databases to net.sources > along with a document that describes the format that they are in. > > I have created a library of C routines for reading/writing/creating > Object File Format files... > I'm not sure about distributing the sources on the network, but if > there is enough demand, perhaps I can twist some upper-management > arms to let me do such a thing. Please do post the sources if humanly possible. I have been looking for some reasonable file format that I can use where I stand a snowballs chance in hell of exchanging info with others easily. This seems to fit the bill fairly well as far as my application (ray tracing) is concerned. I would really hate to have to reinvent the wheel (which I've already started to do in a limited way) if there already exists something that I can get a hold of easily. Posting the sources would help guarantee that more people would use this file format and might help spawn a comp.graphics.objects which I for one could use desperately. Al Amaral -- uucp: ...decvax!elrond!amamaral I would rather be a phone: (603) 885-8075 fool than a king... us mail: Calcomp/Sanders DPD (PTP2-2D01) Hudson NH 03051-0908
fnf@mcdsun.UUCP (Fred Fish) (12/18/86)
In article <507@elrond.UUCP> amamaral@elrond.UUCP (Alan Amaral) writes: >Please do post the sources if humanly possible. I have been looking for >some reasonable file format that I can use where I stand a snowballs chance >in hell of exchanging info with others easily. This seems to fit the You might want to check out the "IFF" format used by most programs on the Commodore Amiga. The code for reading and writing files is public domain. You can see a written spec by finding your closest computer literature store and looking in the "Amiga ROM Kernel Manual" (a two volume set). -Fred -- =========================================================================== Fred Fish Motorola Computer Division, 3013 S 52nd St, Tempe, Az 85282 USA {seismo!noao!mcdsun,hplabs!well}!fnf (602) 438-5976 ===========================================================================
chapman@fornax.uucp (John Chapman) (12/19/86)
> > I have posted most of our useful 3D graphics databases to net.sources > along with a document that describes the format that they are in. We did not seem to get the first 5 files of this posting. I have a use for the information so I would appreciate if someone could offer to email them to me. Thanks in advance, john chapman {watmath,ihnp4,uw-beaver}!ubc-vision!sfucmpt!sfulccr!chapman School of Computing Science Simon Fraser University Burnaby, B.C. Canada V5A 1S6 *** REPLACE THIS LINE WITH YOUR MESSAGE ***
falk%peregrine@Sun.COM (Ed Falk) (12/20/86)
In article <213@mcdsun.UUCP> fnf@mcdsun.UUCP (Fred Fish) writes: >In article <507@elrond.UUCP> amamaral@elrond.UUCP (Alan Amaral) writes: >>Please do post the sources if humanly possible. I have been looking for >>some reasonable file format that I can use where I stand a snowballs chance >>in hell of exchanging info with others easily. This seems to fit the > >You might want to check out the "IFF" format used by most programs on >the Commodore Amiga. 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. -ed falk, sun microsystems
news@cit-vax.Caltech.Edu (Usenet netnews) (12/24/86)
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 __@/