Newsgroups: comp.graphics
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!news.UVic.CA!csr!bcorrie
From: bcorrie@csr (Brian  Corrie)
Subject: Re: Scene Description Standard (RenderMan fits the bill)
Message-ID: <bcorrie.673028299@csr>
Sender: news@sol.UVic.CA
Nntp-Posting-Host: csr.uvic.ca
Organization: University of Victoria
References: <1991Apr30.003612.16050@mks.com>
Date: 30 Apr 91 16:18:19 GMT

I apoligize for posting twice, but on re-reading Davids article, I thought it
may have deserved a more extensive explanation of what the RenderMan interface
includes. If you haven't seen my previous posting, it just gives the ISBN
number of the ``RenderMan Companion''.

david@mks.com (David Rowley) writes:
>One of the harder problems in producing snazzy computer graphics seems
>to be the modelling, rather than the rendering.  One reason for this is
>the lack of a standard modelling format.

...and the lack of modelling software. Compare the number of PD renderers
to the number of PD modellers and you will see what I mean.

>Would it make sense to define a new, say text-based, format to describe
>a world, such that a renderer could use as much information from it
>as possible, and chuck the rest ?

See my previous posting on RenderMan for a brief description of Pixar's
rendering interface.

>There could be the standard sort of NFF, Rayshade type primitives
>(sphere, ellipsoid, cone, polygon, box, etc) with a set of filters

RenderMan has them all, along with patches (NURBS and other flavors) and CSG.

>that would convert higher-level primitives to lower-level ones for
>those renderers that need that lower level.  For example a sphere
>could be tessellated into triangles, or polygons, for those renderers
>without a general 'sphere' primitive.  Spline objects could be
>translated into polygons.  The filters would be written in portable 'C'
>so that the transformations were available on all platforms.

>In fact a filter could be created to convert *everything* down to
>polygons, then a display program could simply display a wire-frame
>rendering as a fast model preview.

As a matter of fact, Pixar's renderers do exactly that, except they coerce
a realistic image out of their polygons. They create sub-pixel polygons
(that is polygons that are smaller than a pixel) out of all their primitives
and render that. It simplifies the process, and allows some nifty effects to
be done easily.

>Filters could also be written to translate this standard format into
>a format accepted by a particular renderer.

>Another filter could take a set of polygons and produce a hidden-line
>rendering.

>By developing general-purpose primitive-conversion filters, all renderers
>would be able to work with all scene descriptions, at least to some extent.

>Perhaps a CSG filter could convert a CSG description to polygons for those
>renderers without that capability.  Some of these filters may be quite
>complex.

>Special-purpose filters could be created to generate 3D text, surfaces
>of rotation, or extrusion.

That is the idea behind RenderMan. A renderer supports what it can, and ignores
what it can't. To be a RenderMan compliant renderer, there is a minimal amount
of functionality that must be supported. It is the job of the renderer to take
the RenderMan description and convert that to something it understands. To do
this, it is possible that filters like you describe above would be used.

>Surface descriptions are harder than modelling the geometry of a scene.
>There should be enough described in the standard to handle the most
>common parameters, such as ambient, diffuse, specular, etc, but
>there should be a general way of handling procedural surfaces such as
>wood, marble, etc.

The RenderMan Shading Language fits the bill here. Some great effects have
been created with this language. Essentially, the renderer is responsible
for interpreting a C like shader description for each surface. Voila,
programmable shaders. Just like that! OK, maybe it ain't that easy, but its
possible. Check out the RenderMan Companion for some pretty slick pictures.

>Interactive X-Windows, Microsoft Windows, or whatever applications could
>be created that would read and write this format, to allow manipulation
>of the world.  Those without a modeller could craft scene descriptions
>by hand.

>Does it make sense ?  Anyone interested ?

In summary, RenderMan is a scene description language, and thats it. Its not
a modeller and its not a renderer. It IS the interface betwen the two.
It is a powerful scene description language. The problem now is that
few rendering systems can support the ``minimal'' amount of functionality
that is required before you can say the renderer is RenderMan compliant.

On the modeling side, many modelling systems output the RenderMan Interface
Bytestream (RIB) that is the RenderMan language. This is the easy part, since
you just have to pick the appropriate RIB primitves and output them. Little
extra work is required. What I would like to see is a modeller that supports
the full range of the RenderMan interface. What a system that would be....

8-)

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

Hope this helps and clarifies things a bit. I apoligize for the two posts.

	B
--
                  Brian Corrie (bcorrie@csr.uvic.ca)
Under the most rigorously controlled conditions of pressure, temperature,
volume, humidity and other variables, the organism will do as it damn well
pleases. Sounds like some of the code I have written......  8-)
