Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!eru!hagbard!sunic!liuida!isy!lysator.liu.se!zap From: zap@lysator.liu.se (Zap Andersson) Newsgroups: comp.graphics Subject: Re: More Scene Description Standard (a bit long) Keywords: NFF Message-ID: <614@lysator.liu.se> Date: 4 May 91 17:48:24 GMT References: <30137@rouge.usl.edu> <248@rins.ryukoku.ac.jp> <1991May1.135548.27865@mks.com> <1991May2.092151@anusf.anu.edu.au> Sender: news@isy.liu.se (Lord of the News) Organization: Lysator Computer Club, Linkoping University, Sweden Lines: 88 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)