Newsgroups: comp.graphics Path: utzoo!utgpu!watserv1!watmath!mks.com!david From: david@mks.com (David Rowley) Subject: Re: Scene Description Standard Date: Wed, 1 May 91 13:55:48 GMT Message-ID: <1991May1.135548.27865@mks.com> Organization: Mortice Kern Systems, Waterloo, Ontario, CANADA References: <30137@rouge.usl.edu> <248@rins.ryukoku.ac.jp> Many people have suggested Renderman as being ``the answer''. What I'm really looking for is something more extensive than NFF or OFF but much less ambitious than Renderman. Having to write a full Renderman 'compiler' just to use a scene description seems overkill to me. I want to see something that enables the exchange of modeled objects, in a simple portable way. The standard should be able to be read on even the smallest of machines, by the simplest of renderers. One of the main reasons it seems that the teapot surfaces all over the place is that it is one of the most readily available models, found in a number of different formats. People should be able to trade models in the same way people are currently trading 'GIF' images. Is the RIB format simply a Renderman program compiled into a bytestream ? If it is a reasonable subset, perhaps it could be used. Unfortunately it is not documented (or even really discussed) in Upstill's Renderman Companion. I like the programmatic approach of Renderman, but the overhead of interpretation just to get at the data is too high. The shader language is particularly neat, and perhaps that is a reasonable way to describe that portion. I'd like to see the programmatic approach used at a higher level, to *create* scenes modeled in this format. This means that the user of the data does not need to understand the same programming language. There is also Pixar's copyright limitations on Renderman that could cause problems. They do license the interface without charge, but they have the right to refuse to do so. Are they likely to approve a public domain implementation ? One person mentioned a lisp-style format. This is more what I had in mind. It should be something that can be parsed in a simple manner. It should be trivial to write a filter to convert the standard format to the specific input format of a renderer. The main point being keep it as simple, yet extensible, as possible. You shouldn't need Yacc to parse it. David -- ll // // ,~/~~\' David Rowley /ll/// //l' `\\\ Mortice Kern Systems Inc. / l //_// ll\___/ 35 King Street North, Waterloo, ON, Canada N2J 2W9 O_/ 519/884-2251, FAX 519/884-8861, david@mks.com