Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!brunix!cs.brown.edu!dbc
From: dbc@cs.brown.edu (Brook Conner)
Newsgroups: comp.graphics
Subject: Re: Scene Description Standard (Renderman isn't good enough)
Message-ID: <74147@brunix.UUCP>
Date: 1 May 91 15:51:21 GMT
References: <1991Apr30.211131.7166@nntp-server.caltech.edu>
Sender: news@brunix.UUCP
Organization: Brown Computer Science Dept.
Lines: 84

In article <1991Apr30.211131.7166@nntp-server.caltech.edu>, woolstar@nntp-server.caltech.edu (John D. Woolverton) writes:
|> 
|>    I would love to have a standard interface to work with
|> (from both sides: modeling and rendering).  However my investigation
|> of RenderMan has been _very_ dissapointing.
|> 
|>    Perhapse to the world of 3D Z-buffers and other scan line
|> rendering programs, RenderMan is enough.  But for work in
|> RayTracing and beyond, there are too many things missing.

Quite agreed. RenderMan has only the slightest concessions
to other rendering paradigms -- loopholes in the shading language
for ray casting or radiance calculation. The fact that the
RenderMan Interface has builtin support fo depth maps to
calculate shadows shows just how Pixar expects you to do things.
An abstract scene description it is not.

|> 
|>    Conceptually, Renderman seems to be designed like PostScript.
|> One renderman file, one image.  While this works for the printed
|> page, animations and 3D graphics have continuity across frames
|> that RenderMan cannot describe or take advantage of.

I think Pixar has even made the comparison between RenderMan and PostScript
(notice the funny capitalization).  And you're right, its pretty
useless for nice things like interfrace coherency.

|>    Renderman is also grossly inefficient for representing
|> polygons, as it takes a [vertex, vertex, vertex, close] form for
|> representing each face instead of a list of verteces and then a
|> face list.

But its still O(n) space :-)

|>    Finally the concept of an actor/object is non-existant
|> in RenderMan.  There is no grouping of faces with different
|> properties or relationships defined.

Maybe in RIB, but the C protocol is pretty PHIGS-like in its
structure.  Of course, PHIGS is hardly an example of a
sophisticated, actor or object based environment.

|>    While one could take one's own model from another system
|> and extract the Renderman Commands for it, it does not seem
|> possible to go the other way.  Witness all the modeling programs
|> that support the RenderMan interface, but use their own 
|> formats for working data (scene and objects).  [all of them!]

Yes, it would be like converting PostScript to some other
vector drawing format.  In general, it isn't possible without
loss of a lot of information.

|>    PLEASE SOMEONE!  Work on a scene description file format
|> that will describe an animation or scene, not just the
|> resultant list of polygons.
|> 
|> My proposal:
|> 	One object format that includes geometry primatives
|> and surface descriptions.
|> 	One model format that describes position and motion
|> of objects in a scene.
|> 	Extentions to both for specific shading and 
|> (for ray tracing) geometry organization (bounding boxes...).

My opinion:  A scene description broken down into Modeling,
Animation, and Rendering components (what you have suggested)
is woefully inadequate.  Suppose your constructive solid geometry
objects change over time?  Maybe your surface attributes do, too.
Perhaps you want animated deformations.  In short, nontrivial
scenes will require a richer environment than Model - Animate - Render.
M-A-R is certainly the traditional graphics pipeline, but it is not
the way to go for anything more than flying logos.

|> 
|> 	John D. Woolverton, Video Bits
|> 	woolstar@cobalt.caltech.edu

Brook

-- 
Brook Conner		| Klacktoveedsedstene
Brown Computer Graphics	| Fortune sez: Brook's Law -- Adding manpower to a late
dbc@cs.brown.edu     	|  	software project makes it later
uunet!brunix!dbc dbc@browncs.bitnet   Box 1910 Brown U Prov RI 02912