Newsgroups: comp.graphics
Path: utzoo!utgpu!watserv1!maytag!mks.com!david
From: david@mks.com (David Rowley)
Subject: Re: Scene Description Standard
Date: Thu, 2 May 91 14:15:48 GMT
Message-ID: <1991May2.141548.28966@mks.com>
Organization: Mortice Kern Systems, Waterloo, Ontario, CANADA
References: <248@rins.ryukoku.ac.jp> <1991May1.135548.27865@mks.com> <bcorrie.673121202@csr>

In article <bcorrie.673121202@csr> bcorrie@csr (Brian  Corrie) writes:
>david@mks.com (David Rowley) writes:
>
>>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.

	Where can I get a description of the RIB format ?  It could
	be used as a standard format, since RenderMan is likely to
	be fairly popular.  Like it or not.  A RIB translator
	could transform the more complicated RIB primitives into
	simpler ones that all renderers could understand.
	(polygons, triangles, whatever).

>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.
	Although it's just another format, it has some high-powered
	backing, and isn't likely to go away any day soon.

>>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.

	Someone pointed me to P3D from Pittsburgh Supercomputing Center,
	which is based on a simple lisp interpreter.  It comes close,
	but I still think a programmatic approach embedded within
	the scene description language is a liability.  Programs
	should be used to *generate* this stuff.  The reason I like
	the lisp-style *syntax* is that it is easy to parse.

-- 
     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
