Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!rice!uupsi!pixar!aaa
From: aaa@pixar.com (Tony Apodaca)
Newsgroups: comp.graphics
Subject: Re: Scene Description Standard
Summary: The real scoop on RenderMan
Keywords: RenderMan, RIB, modeling languages, animation languages
Message-ID: <1991May14.015051.10455@pixar.com>
Date: 14 May 91 01:50:51 GMT
References: <1991Apr30.003612.16050@mks.com>
Sender: news@pixar.com (Usenet Newsmaster)
Organization: Pixar -- Point Richmond, California
Lines: 171
Nntp-Posting-Host: woody


	There has been a lot of traffic about what RenderMan is and is not
in the past couple weeks, so I hope I can clear up some of the confusion.
My credentials: currently Chief Architect of the RenderMan Interface, and
one of the Unknown Implementors of both of Pixar's image synthesis products.
	First, I must apologize for the untimeliness of this post.  As I
type this, it is May 12, and only today has our news feed deigned to send us
your postings from April 30!  A friend at UCSC has sent me some postings
up through May 9 (thanks Rob!), but I have not seen the whole thread.
If I cover "old ground", I apologize.
	This post is likely to be long, because I am (too darn) longwinded.
I hope those who are interested will not 'n' this article purely because
of it's length.

	The two documents that describe RenderMan are the Specification
(the current version is 3.1, printed December 1989) and the book,
"The RenderMan Companion" (written by Steve Upstill).  The Specification
is the true source, and is available from Pixar (1001 W. Cutting Blvd,
Richmond, CA, 94804, (415)236-4000) for $20.  We don't make any profit
on that, $20 doesn't quite cover printing costs and postage (particularly
on foreign requests, of which we get a lot).  The book is published by
Addison-Wesley, ISBN 0-201-50868-0.  The "Companion" is cool because it
gives lots of examples and pictures, and is not nearly as technical as
the spec.  The only problem is that the "Companion" uses C to demonstrate
RenderMan, as it was written before the RIB language was codified.

	I want to correct some factually incorrect statements that have
been made about RenderMan.  Someone mentioned...
> Renderman is grossly inefficient for polygons, as it takes a
> [vertex, vertex, close] instead of a list of vertices and a face list.
Check out RiPointsPolygons().  I think this will do what you want.
	Someone claimed that Pixar did not use RenderMan and RIB for its own
animations.  We most certainly do, and we are quite proud of it.
We sell what we use, we use what we sell.
	People are worried about how hard it is to parse RIB.  Believe me,
you don't need yacc to parse RIB.  It is very simple.  To be honest, I
am quite surprised there isn't a PD file reader already.  I would write one,
but I'm not allowed (employment contract and all).
	Several people were worried about copyrights and licenses and such.
Let me put the record straight.  Pixar wants RenderMan to be "ubiquitous"
(such a nice word!).  That means STANDARD.  We want other people to write
renderers, because if they don't, what good is it to call it a standard?
One company does not agreement make.  Sure, our marketing department would
be really happy if our engineering department produced the best such
renderer available, but as a company, we completely recognize the need
for honorable competition, and we look forward to it.
	So what's the deal with licenses?  We retain the copyright and require
licensing for our own protection, and for the protection of the consumer.
Who is helped if someone announces a RenderMan product and they lie?  Noone,
obviously.  We do not restrict or charge fees or make it difficult an any way
for someone who tells the truth to get a full license.  We've given out many.
If anyone out there has had a problem in this regard, please contact me
personally, and I will get it straightened out.  'Nuff said.
	Finally, several people were concerned that RenderMan only "works"
for Pixar's Reyes-style renderer.  I have heard this on occassion from
various places.  Sometimes the evidence is "Look, displacements can't be
done in a ray tracer, QED".  The fact is, RenderMan was designed to be used
by any renderer, anywhere.  Sure, some features are algorithm-specific,
because people who write such renderers asked for them to be there.  There
are things in RenderMan that can't be done by Reyes that CAN be done by
a ray tracer (tranluscent volumes, for example).  But these are all "optional".
It is a bit much to go into exactly what this means (it's in the spec), but
suffice it to say, if the renderer can't do it, it is free to ignore it.
If there are any examples of anything in the RenderMan Interface Spec which
clearly are impossible in a ray tracer, or in any other mainstream algorithm,
I would like to hear about it...and fix it!  If it were true, I would have
failed, and I don't want to fail.
	Being "Chief Architect", I am privy to a lot of private plans of
various companies using RenderMan, and it would be indiscreet for me to let
on what I know, even by innuendo.  Let me just say, there is more in store
than just bug-fixes for Reyes....

	I will now launch into a long explanation of why RenderMan
was designed the way it was designed.  I think there are some valuable
lessons for the person who designed the next modeling and rendering interface.
If you are already bored, hit 'n' now.

	By now, everyone understands the difference between C calls
to a RenderMan library and RIB.  Yes, RIB is (for all intents and purposes)
simply a metafile format for the C library.  Why did we choose a C
library as the "fundamental" binding, rather that write our own procedural
language?  Well, because it seemed like the right thing to do at the time.
This is not a flippant comment.  We (actually Pat Hanrahan, the original
father of RenderMan) examined other graphics packages and standards closely.
He decided that a procedural interface, in the long tradition of GKS, PHIGS
and SGI's GL, was the most flexible and gave the users the most bang per
buck.  It is simple to write a metafile format for a procedural interface,
but it is very awkward to write a procedural interface for a language
(ex: Postscript wrappers from a C program).
	One must remember the domain that RenderMan was set out to cover.
We wanted a standardized interface between modeling programs and rendering
programs.  All sorts of rendering programs, from SGI hardware renderers to
Reyes to ray tracers, and everything in between.  There were two totally
different ways to approach this problem: 1) provide a standard set of
really simple primitives that absolutely any renderer could eat, and put
the burden on the modeller to convert anything more interesting that *it*
knew about into these simple primitives; 2) provide all of the primitives
that any modeller could possibly want, and put the burden on the renderer
to be so complex that it could handle anything.  Any new rendering interface
has to face this question, and believe me, it is the hardest one of all.
We tried to compromise, to fill as many people's needs as we could without
getting PL/1 (anyone remember PL/1?).  We provided a "very rich" set of
primitives, anything that renderers might reasonably be expected to be
able to "take advantage of", but do not solve every modelling problem.
For example, we take spheres directly, because ray tracers can certainly
trace spheres a lot faster than some collection of 2000 triangles.
Similarly, we take CSG and object hierarchies directly.  On the other hand,
we don't take surfaces of revolution directly.  These are easily
described with the other primitives, and offer renderers no real advantage.
	So, we made our decision.  What kind of flack do we get for it?
You might be able to guess: people who are writing renderers say, "This
interface is too darn complex.  Noone could ever meet it."  People who are
writing modellers say, "My modeller has the one neato concept that really
ought to be in the interface, can't you see your way clear to add it?"

	But what about animation?  Doesn't that require a procedural
interface?  We struggled with two important constraints which many people
don't think about: 1) the animation that the average Joe on the street
does is simple now, but is going to get more and more complex as computers
and renderers get faster and faster; 2) any procedural language which
we were to define has to be better than C.
	What do we mean by simple animation?  We all know the type...
flying logos, camera moves over static scenes, robot arms and spaceships.
Basically, simple rigid motions over repetitive objects.  Our own
animation has shown us that people are bored of this, and want to move
to complex animation: soft, squishy surfaces which deform as they move,
faces and bodies, scenes with zillions of objects.  Everyone wants to
see and do this type of animation, but what does it do to the image
description?  Well, for one thing, almost NOTHING is constant
from one frame to the next.  Oh, the occasional desk or wall, but the
size of the data in the description of the wall is microscopic in
comparison to size of the data in the description of the baby's crying face.
It makes a lot of sense to optimize for the big, changing data, rather
than the small, static data.  And everyone who does these kinds of
animations has their own special tricks for managing the huge amount of
data this kind of animation requires.  Some things might be simple,
like a particle system or an evolving fractal, but for some people it
is gargantuan systems of differential equations, hydrodynamic equations
of the third order, or even giant databases of the complete motion of every
one of the individual control points (vertices) in the scene.
	Could we design a language which could encompass all this, and do
it better than Lisp or C?  Hardly.  General purpose languages are just
too powerful (imagine that!).  Special purpose languages only help if the
domain is very small (Postscript), or if they are pure amplifications of
a general purpose language (Shading Language).  C/Lisp/Ada are just too good.
(Okay, maybe not Ada. ;-) )

	So, what have we learned?  Modeling languages are hard.  Very hard.
This is not to say impossible, and I look forward to the day when a smart
person solves this problem.  But Pixar didn't (and doesn't) know the answer.
Pixar has at least 3 modeling and animation languages we use, each of which
handles some things very well and other things very poorly.
	The original poster said he was looking for a "new, text-based,
standard modelling format", and then went on to describe some features
of a rendering format not too different from RenderMan (some primitives,
shading parameters, etc.).  Other posters have described their needs for
a much more general animation language.  I encourage people to keep these
two concepts separated.  The data necessary for describing (good, complex)
modeling and animation is very different from the data necessary to do
a photorealistic rendering of a single frame from this animation.
	And beware the temptation to "add programming constructs" to a
line-oriented database format.  It will end up ugly and not very useful.
If you want a good language, you must design it as a language from the start.

	If you have made it this far, you are brave indeed.  If anyone has
specific questions or comments about RenderMan, I'd be happy to answer them.

-- 
UUCP:		{sun,ucbvax}!pixar!aaa		Tony Apodaca
Internet:	aaa@pixar.com			Pixar, Richmond, CA, USA
    "And in the end, the love you take is equal to the love you make."