Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!rice!uupsi!pixar!markv
From: markv@pixar.com (Mark VandeWettering)
Newsgroups: comp.graphics
Subject: Re: (Renderman isn't good enough) Says Who? : -)
Message-ID: <1991May13.175749.9045@pixar.com>
Date: 13 May 91 17:57:49 GMT
References: <1991Apr30.211131.7166@nntp-server.caltech.edu>
Sender: news@pixar.com (Usenet Newsmaster)
Organization: Pixar -- Point Richmond, California
Lines: 81
Nntp-Posting-Host: roger

In article <1991Apr30.211131.7166@nntp-server.caltech.edu> woolstar@nntp-server.caltech.edu (John D. Woolverton) writes:

	Mr. Woolverton has some interesting comments, which perhaps should
	be addressed....

>   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.
	
	Well, it is too bad that you find it so disappointing.  Many people
	are absolutely ecstatic with it, and continue to use it.  Many are
	also pleased that Pixar has taken the trouble to standardize a 
	graphics format like RenderMan.  You later draw a parallel to 
	PostScript, and indeed, we would like RenderMan to be the PostScript
	of 3-D imaging.  That is not to say that RenderMan is the ultimate
	in designs (it is, but I won't say that ;-)  but it does have the 
	advantage of being standardized and "in the real world".


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

	Such as?  Before I began working at Pixar, I was most impressed
	the shade language design, precisely because it did NOT force a 
	particular rendering algorithm (z-buffer vs. ray tracing vs. radiosity)
	on the user.  I personally believe that radiosity is a bit more 
	complicated than ray tracing, but I believe that all are doable within 
	the confines of the current shade language design.

	If you don't believe me, reread the part on illuminate/illuminance,
	Kajiya's "Rendering Equation" paper, and think about bi-directional
	reflectance functions.  

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

	Oh, gadzooks.  Niggly details.  

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

	RenderMan (regardless of what some people believe) is not 
	a modeler.  It is not even a modelling language.  It is a language
	which describes how scenes are to be rendered.  It allows many 
	high level constructs (such as CSG, nested transformations, etc...)
	because it is convenient for some modellers to put these out.
	RenderMan tries to be accomadating to modellers, but by no means is 
	there enough information in a .rib file to feed an adequate modeller.
	RIB is perhaps a "write only format", similar to PostScript again.
	(One doesn't expect to reconstruct a LaTeX file from PostScript either).

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

	RenderMan does fulfill the first quite flexibly.
	RenderMan never claimed to fulfill the second.

	The third is interesting, but forces a particular rendering style 
	onto the user (why is your geometry organization better than mine?).
	Perhaps my automatic bounding volume generator is much better than
	you can do in practice.  I mean, you may not know details about
	how rays are cast, and the relative costs.  The renderer definately
	knows, and perhaps can do a better job than a "third party" could.


	Anyway, hope this was thought provoking and informative.

Mark VandeWettering