Newsgroups: comp.graphics
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!pixar!mccoy
From: mccoy@pixar.com (Dan McCoy)
Subject: Re: Scene Description Standard (Renderman isn't good enough)
Message-ID: <1991May14.030340.10653@pixar.com>
Sender: news@pixar.com (Usenet Newsmaster)
Nntp-Posting-Host: valkyrie
Organization: Pixar -- Point Richmond, California
References: <1991Apr30.211131.7166@nntp-server.caltech.edu>
Date: Tue, 14 May 1991 03:03:40 GMT

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.

Sorry to hear that.  I believe some of your complaints are based on 
a misunderstanding of the RenderMan Interface. 
I'll try to clarify.

>   Perhaps 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.
>
>   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 take this to mean that you dislike the lack of animation control
information in the RenderMan Interface.
This is, arguably, a weakness of the current RenderMan standard.
So yes, as it stands RenderMan is a "scene description language" and not
an "animation description language".
Control information could possibly make its way into the standard 
in the future.
Currently, the time it takes to render a high quality image dwarfs 
the time involved in reading a new file for each frame.
That is even more true of ray tracers and beyond than it is with the
"other scan line rendering program" that we currently sell.

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

Did you look at the RiPointsPolygons call? It sounds like what you want. 
Besides, if you want efficifient descriptions of objects, then patches, 
patch meshes, quadrics, and NURBS are all superior to polygons.
Also much information required by a high quality renderer is lost if curved
surfaces are expressed as polygons.

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

Current implementations of RenderMan renderers may not have the features 
you want.  But the RenderMan Interface provides flexible support 
for this sort of extension with the RiAttribute call along with 
RiAttributeBegin/End blocks.  The set of attributes that can be specified 
is not closed.  As implementations of RenderMan compatible programs arise, 
they are free to add implementation specific attributes.

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

This is a chicken-egg sort of problem.
The interface hasn't been around that long.
So far the only reason that people have modified their modellers to output
RenderMan compatible files (RIB files) is to allow them to be renderered
by Pixar's renderer.  Now that many modellers can output their geometry
in RIB format, I'm sure you'll start seeing programs that read RIB files
as well as write them.  

>   PLEASE SOMEONE!  Work on a scene description file format
>that will describe an animation or scene, not just the
>resultant list of polygons.

The RenderMan Interface provides much more than a "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...).

RiBound provides bounding boxes.
The only thing you ask for that isn't covered by the current RenderMan 
Interface is motion (beyond motion blur within a frame).  
It could be argued that this is outside the scope of a "scene description" 
standard.  

An example of how to provide what you want without starting from scratch:
Motion control could be provided as a separate control file.
This control file along with a properly formatted RIB file could either 
be read by filter program which combines them and outputs to a current 
level RenderMan renderer.
Or the files could be read by a new smarter renderer that could make use of
the control information. 
This has the advantage of being able to compactly express more than one 
animation sequence for a given geometry file.

Dan McCoy	Pixar