Newsgroups: comp.graphics
Path: utzoo!utgpu!watserv1!watmath!mks.com!david
From: david@mks.com (David Rowley)
Subject: Re: Scene Description Standard
Date: Wed, 1 May 91 13:55:48 GMT
Message-ID: <1991May1.135548.27865@mks.com>
Organization: Mortice Kern Systems, Waterloo, Ontario, CANADA
References: <30137@rouge.usl.edu> <MATT.91Apr30142917@mandala.think.com> <248@rins.ryukoku.ac.jp>

Many people have suggested Renderman as being ``the answer''.

What I'm really looking for is something more extensive than NFF or OFF
but much less ambitious than Renderman.  Having to write a full
Renderman 'compiler' just to use a scene description seems overkill to
me.  I want to see something that enables the exchange of modeled objects,
in a simple portable way.  The standard should be able to be read on
even the smallest of machines, by the simplest of renderers.  One
of the main reasons it seems that the teapot surfaces all over the
place is that it is one of the most readily available models, found
in a number of different formats.  People should be able to trade
models in the same way people are currently trading 'GIF' images.

Is the RIB format simply a Renderman program compiled into a bytestream ?
If it is a reasonable subset, perhaps it could be used.  Unfortunately
it is not documented (or even really discussed) in Upstill's Renderman
Companion.

I like the programmatic approach of Renderman, but the overhead of
interpretation just to get at the data is too high.  The shader
language is particularly neat, and perhaps that is a reasonable
way to describe that portion.  I'd like to see the programmatic
approach used at a higher level, to *create* scenes modeled in this
format.  This means that the user of the data does not need to
understand the same programming language.

There is also Pixar's copyright limitations on Renderman that could cause
problems.  They do license the interface without charge, but they
have the right to refuse to do so.  Are they likely to approve a
public domain implementation ?

One person mentioned a lisp-style format.  This is more what I had
in mind.  It should be something that can be parsed in a simple manner.
It should be trivial to write a filter to convert the standard format
to the specific input format of a renderer.  The main point being
keep it as simple, yet extensible, as possible.  You shouldn't
need Yacc to parse it.

David

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