Newsgroups: comp.graphics
Path: utzoo!utgpu!watserv1!maytag!mks.com!david
From: david@mks.com (David Rowley)
Subject: Re: More Scene Description Standard (a bit long)
Date: Thu, 2 May 91 14:09:29 GMT
Message-ID: <1991May2.140929.28626@mks.com>
Keywords: NFF
Organization: Mortice Kern Systems, Waterloo, Ontario, CANADA
References: <248@rins.ryukoku.ac.jp> <1991May1.135548.27865@mks.com> <1991May2.092151@anusf.anu.edu.au>

In article <1991May2.092151@anusf.anu.edu.au> drw900@anusf.anu.edu.au writes:
>In article <1991May1.135548.27865@mks.com>, david@mks.com (David Rowley) writes:
[stuff deleted]
>	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. 

	This is what I had in mind.  A simple declarative scene
	description, more sophisticated than NFF so that a rich
	geometry could be represented (NURBs, CSG, etc), with
	a set of filters that could transform the more sophisticated
	primitives to lower-level ones (with the appropriate
	filters you could take a highly sophisticated scene,
	transform it to only use the 'polygon' primitive, and
	render it on the simplest of renderers).

	As you say, there are many ways you could generate
	these descriptions programmatically.

	One ideal example of a use for this is the 'Algorithmic
	Beauty of Plants' book.  It wants to use a renderer
	as a back-end, and decided to use Rayshade as its standard
	format.  This sort of scene description standard would
	allow the generated models to be rendered by MTV, DKBTrace,
	Rayshade, RenderMan, etc.

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

	Sounds good to me.  This is basically how the free JPEG
	(image compression) group was founded.

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

	Problem with Yacc is that a lot of people don't have it or
	understand it.  It also makes extending the language complicated,
	when so many parties are involved.
	I would *really* prefer to stay away from it.  A simple
	lisp-style syntax should suffice.

>	The biggest hurdle would be to design the shading/texturing
>instructions. 
>
	Agreed.  But then these are the sorts of things that are
	very specific to the renderer.  If the basic attributes
	could be handled (colour, transparency, reflectivity, etc),
	then the consumer of the scene could tinker with the rest.

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


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