Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!munnari.oz.au!manuel!anusf.anu.edu.au!drw900 From: drw900@anusf.anu.edu.au ("Drew R Whitehouse") Newsgroups: comp.graphics Subject: More Scene Description Standard (a bit long) Keywords: NFF Message-ID: <1991May2.092151@anusf.anu.edu.au> Date: 1 May 91 23:21:51 GMT References: <30137@rouge.usl.edu> <248@rins.ryukoku.ac.jp> <1991May1.135548.27865@mks.com> Sender: news@newshost.anu.edu.au Reply-To: drw900@anusf.anu.edu.au Organization: Australian National University Supercomputer Facility Lines: 72 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 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. 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.