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: More Scene Description Standard (a bit long)
Message-ID: <bcorrie.673201580@csr>
Keywords: NFF
Sender: news@sol.UVic.CA
Nntp-Posting-Host: csr.uvic.ca
Organization: University of Victoria
References: <30137@rouge.usl.edu> <MATT.91Apr30142917@mandala.think.com> <248@rins.ryukoku.ac.jp> <1991May1.135548.27865@mks.com> <1991May2.092151@anusf.anu.edu.au>
Date:  2 May 91 16:26:20 GMT

drw900@anusf.anu.edu.au ("Drew R Whitehouse") writes:

>In article <1991May1.135548.27865@mks.com>, david@mks.com (David Rowley) writes:
>|> 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,

>[stuff deleted]

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

>	I'm also wondering whether it's a good idea to put so many
>"smarts" into your scene description language and to spend ages
>writing yacc code for your raytracer (I know, I've just been through
>it). I think that a look at the old unix filter philosophy is probably
>a good idea - write small tools and filters rather than monolithic
>programs.  As though writing a sophisticated raytracer isn't enough
>for one program !

>	So perhaps rather than writing yet another programming flaky
>language why not just design a more powerful "dumb" scene description
>language, just a more sophisticated version of NFF perhaps. Then when
>you want to get fancy use an already developed language to put in the
>control structure. A few possibilities would be

Again, on really thinking about this, I beleive it is what RenderMan does.
RIB is the powerful (many sophisticsted primtives, CSG, etc) but dumb
(no programming constructs) scene description. The C binding is the way
to get control over program flow and more flexibility. Hmmmm, do you think
that Pixar actually knew what they were doing???? My earlier comments about
wanting more power in RIB may have been out to lunch when you look at it the
way Drew does.

>1. a set of lisp defun's that produce the basic element's of the scene
>description language, then all the higher function's (object
>definition and instantiation, procedural geometry placement etc) could
>be written in lisp. This could easily be done in emacs lisp (wow, a
>renderer will a full editor interface...:-)

>2. write a set of C subroutines that produce the basic scene
>description elements (like in Eric Haines SPD) and tie them together
>will the excellent TCL embedded language.

>	This scene desription language would be something that could
>possibly be designed on the net (in comp.graphics.research ??) Then
>everyone could have a say in making sure that it has the features that
>they need for their particular renderer. 

>	A way this could be organized would be for one person to made
>"the keeper" of the code, responsible for adding features after they
>have been discussed on the net. Then as each new feature was added an
>updated documant would be posted, and the next feature to be added
>could be discussed. The current NFF document would be a start.

>	It would be nice if it could be made so plain that a yacc
>parser wasn't neccessary, however that's probably bit ambitious
>(people use yacc for NFF). It would not need to pretty to the eye, you
>shouldn't ever have to write it by hand. The yacc definition could
>then be PD and freely distributed to all comp.graphics people to put
>into there renderer's.

>	The biggest hurdle would be to design the shading/texturing
>instructions. 

An interesting idea, but do we want to introduce yet another one. I am torn
between starting from scratch and basing things on the vast amount of work
that Pixar put into RenderMan. Addmitedly, there are some things I don't like
about RenderMan, but it is pretty powerful. Maybe it would be better to start
from scratch and do it how we want, but I can forsee lots of long debates about
just what it should have in it.... And yes, the shading language would be a
pain in the butt to do, and it would probably end up pretty close to Pixar's
idea of a shading language.

At least it would produce some interesting discussions in our new group 8-)
comp.graphics.research.

>	Maybe we could call it NFF++ ........

>							Drew

>// Drew Whitehouse,                E-mail:  drw900@anusf.anu.edu.au 
>// Visualization Group,            Fax   : +61 (0)6 247 3425 
>// Australian National University, Phone : +61 (0)6 249 5985
>// Supercomputer Facility.
>// GPO Box 4, Canberra ACT Australia 2601.

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