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: Scene Description Standard (RenderMan fits the bill) Message-ID: Sender: news@sol.UVic.CA Nntp-Posting-Host: csr.uvic.ca Organization: University of Victoria References: <1991Apr30.003612.16050@mks.com> Date: 30 Apr 91 16:18:19 GMT I apoligize for posting twice, but on re-reading Davids article, I thought it may have deserved a more extensive explanation of what the RenderMan interface includes. If you haven't seen my previous posting, it just gives the ISBN number of the ``RenderMan Companion''. david@mks.com (David Rowley) writes: >One of the harder problems in producing snazzy computer graphics seems >to be the modelling, rather than the rendering. One reason for this is >the lack of a standard modelling format. ...and the lack of modelling software. Compare the number of PD renderers to the number of PD modellers and you will see what I mean. >Would it make sense to define a new, say text-based, format to describe >a world, such that a renderer could use as much information from it >as possible, and chuck the rest ? See my previous posting on RenderMan for a brief description of Pixar's rendering interface. >There could be the standard sort of NFF, Rayshade type primitives >(sphere, ellipsoid, cone, polygon, box, etc) with a set of filters RenderMan has them all, along with patches (NURBS and other flavors) and CSG. >that would convert higher-level primitives to lower-level ones for >those renderers that need that lower level. For example a sphere >could be tessellated into triangles, or polygons, for those renderers >without a general 'sphere' primitive. Spline objects could be >translated into polygons. The filters would be written in portable 'C' >so that the transformations were available on all platforms. >In fact a filter could be created to convert *everything* down to >polygons, then a display program could simply display a wire-frame >rendering as a fast model preview. As a matter of fact, Pixar's renderers do exactly that, except they coerce a realistic image out of their polygons. They create sub-pixel polygons (that is polygons that are smaller than a pixel) out of all their primitives and render that. It simplifies the process, and allows some nifty effects to be done easily. >Filters could also be written to translate this standard format into >a format accepted by a particular renderer. >Another filter could take a set of polygons and produce a hidden-line >rendering. >By developing general-purpose primitive-conversion filters, all renderers >would be able to work with all scene descriptions, at least to some extent. >Perhaps a CSG filter could convert a CSG description to polygons for those >renderers without that capability. Some of these filters may be quite >complex. >Special-purpose filters could be created to generate 3D text, surfaces >of rotation, or extrusion. That is the idea behind RenderMan. A renderer supports what it can, and ignores what it can't. To be a RenderMan compliant renderer, there is a minimal amount of functionality that must be supported. It is the job of the renderer to take the RenderMan description and convert that to something it understands. To do this, it is possible that filters like you describe above would be used. >Surface descriptions are harder than modelling the geometry of a scene. >There should be enough described in the standard to handle the most >common parameters, such as ambient, diffuse, specular, etc, but >there should be a general way of handling procedural surfaces such as >wood, marble, etc. The RenderMan Shading Language fits the bill here. Some great effects have been created with this language. Essentially, the renderer is responsible for interpreting a C like shader description for each surface. Voila, programmable shaders. Just like that! OK, maybe it ain't that easy, but its possible. Check out the RenderMan Companion for some pretty slick pictures. >Interactive X-Windows, Microsoft Windows, or whatever applications could >be created that would read and write this format, to allow manipulation >of the world. Those without a modeller could craft scene descriptions >by hand. >Does it make sense ? Anyone interested ? In summary, RenderMan is a scene description language, and thats it. Its not a modeller and its not a renderer. It IS the interface betwen the two. It is a powerful scene description language. The problem now is that few rendering systems can support the ``minimal'' amount of functionality that is required before you can say the renderer is RenderMan compliant. On the modeling side, many modelling systems output the RenderMan Interface Bytestream (RIB) that is the RenderMan language. This is the easy part, since you just have to pick the appropriate RIB primitves and output them. Little extra work is required. What I would like to see is a modeller that supports the full range of the RenderMan interface. What a system that would be.... 8-) >-- > 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 Hope this helps and clarifies things a bit. I apoligize for the two posts. 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-)