Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!van-bc!ubc-cs!news.UVic.CA!csr!bcorrie From: bcorrie@csr (Brian Corrie) Newsgroups: comp.graphics Subject: Re: Scene Description Standard Message-ID: Date: 1 May 91 18:06:42 GMT References: <30137@rouge.usl.edu> <248@rins.ryukoku.ac.jp> <1991May1.135548.27865@mks.com> Sender: news@sol.UVic.CA Organization: University of Victoria Lines: 76 Nntp-Posting-Host: csr.uvic.ca david@mks.com (David Rowley) writes: >Many people have suggested Renderman as being ``the answer''. I don't think it is ``the answer'', but it is a step forward. See my post just before (or after, depending on mailers of course) this one for a discussion of some of the faults/omissions of RenderMan. >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. From what I understand, the RIB format is just a scene description, without all of the control flow and other constructs of the C binding. It is still quite rich geometrically, so you are right, most PD type renderers will not be able (mine included 8-) to handle most of the more sophisticated primtives. Unfortunate, but NURBS and CSG are the best ways to describe many objects. Polygons just don't cut it for a lot of things. >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. I agree. I actually thought RIB had the programming constructs as well, until recently. Without them RIB is JAF (Just Another Format 8-), rich as it may be. One thing I just realized: if we loose the programming constructs of the C binding, the RiPointsPolygon mentioned in my previous posting isn't nearly as efficient as it could be. Only duplicate vertices within one polyhedra are avaoided. Better than nothing, but still, it would be nice if RIB could have variables as well, no? >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 ? This I'm not too sure about. Any comments from people out there that have dealt with licensing from Pixar. Anyone form Pixar have any comments. >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 Later, B -- Brian Corrie (bcorrie@csr.uvic.ca) Under the most rigorously controlled conditions of pressure, temperature, volume, humidity and other variables, the organism will do as it damn well pleases. Sounds like some of the code I have written...... 8-)