drw900@anusf.anu.edu.au ("Drew R Whitehouse") (05/02/91)
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.
david@mks.com (David Rowley) (05/02/91)
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
bcorrie@csr (Brian Corrie) (05/02/91)
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-)
zap@lysator.liu.se (Zap Andersson) (05/05/91)
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, Hmmm... Let's see here. Lets not reinvent the wheel AGAIN. But lets take the radial tyre and turn into a bicycle one, ok? Take renderman as it is. Rip out what's impossible in a raytracer (e.g. displacement shading) Throw in what we need: * Named objects that can later be transformed for each frame (perhaps named transformations insted, that can be given new values?) * RayTracing-specific stuff, i.e. RiBeginScheme(RI_OCTREE); RiEndScheme(); * Better 'back door' informatin passing, i.e. things that are implementation dependent but can easily be ignored when reading in. The bigges pain in the *ss is of course shading, and it would be hard to bit the sour apple and do full renderman style shading lingo, sadly. However, I agree with someone who suggested this also be implementation dependent. However "standard" things, like light color, ambient, specular e.t.c. could be in the interface, but fancy stuff should really be implementation dependent (like texture/bump mapping) since there are SO many ways to do it (projective, wrapped e.t.c.). What we probably should have, is that each object references a "material" that may have a "human readable" name, such as "Bright wood" or similar, and when reading in "someone elses" renderdata, the program tries to convert as good as possible, letting the user fix the rest, telling the user that "This is supposed to be bright wood". Other things kan get messy too, I have a real life example: * In my renderer, the fact that a object casts shadows or not is a property of the MATERIAL * In Autodesk 3d Studio it is a property of an OBJECT. When I want to load a 3d studio file into my renderer, I get trouble if there are objects not casting shadows. Other renderers may have projective shemes for texturemapping, (as 3D studio who has semi-projective, i.e. you apply the mapping projectively but the texture coordinates are locked to the verticies) or like mine, where the texture coordinates are either object-space 3d coordinates, or 2d parameter space coordinates! A lot of those messes crop up if you try to make the shading part of the "magic uniform interface". What I say is that the interface should dictate the GEOMETRIES (and I so NO problem using renderman PRIMITIVES) and 'hint' the shading (of course INCLUDE the full shading data for renderer A but that can be ignored when read by renderer B). Now when we have taken renderman, whipped it bad and twisted it around, it's no longer renderman. Lets call it RayMan, or perhaps RayMond? Also, about Pixar patents: A person at Pixar told me (although he is not their official spokesman in these question, so this is not Pixars views, it's his) that anyone could write a Renderman compliant renderer. However, you needed pixars agreement to CLAIM that it was renderman compatible. And then it had to do certain things. So, anyone can create a renderer reading RIB's without payin o'le pixar nothing. But to brag about it.... Just some unsorted thoughts. Apologies are in order for typoes and strange threads... my mind is like that :-) /Z -- * * * * * * * * * * * * * * * * * (This rent for space) * My signature is smaller than * Be warned! The letter 'Z' is Copyright 1991 * yours! - zap@lysator.liu.se * by Zap Inc. So are the colors Red, Green and * * * * * * * * * * * * * * * * * Greenish-yellow (Blue was taken by IBM)