Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!van-bc!ubc-cs!news.UVic.CA!csr!bcorrie From: bcorrie@csr (Brian Corrie) Newsgroups: comp.graphics Subject: Re: Scene Description Standard (Renderman isn't good enough) Message-ID: Date: 1 May 91 17:23:17 GMT References: <1991Apr30.211131.7166@nntp-server.caltech.edu> <74147@brunix.UUCP> Sender: news@sol.UVic.CA Organization: University of Victoria Lines: 138 Nntp-Posting-Host: csr.uvic.ca dbc@cs.brown.edu (Brook Conner) writes: >In article <1991Apr30.211131.7166@nntp-server.caltech.edu>, woolstar@nntp-server.caltech.edu (John D. Woolverton) writes: >|> >|> I would love to have a standard interface to work with >|> (from both sides: modeling and rendering). However my investigation >|> of RenderMan has been _very_ dissapointing. >|> >|> Perhapse to the world of 3D Z-buffers and other scan line >|> rendering programs, RenderMan is enough. But for work in >|> RayTracing and beyond, there are too many things missing. >Quite agreed. RenderMan has only the slightest concessions >to other rendering paradigms -- loopholes in the shading language >for ray casting or radiance calculation. The fact that the >RenderMan Interface has builtin support fo depth maps to >calculate shadows shows just how Pixar expects you to do things. >An abstract scene description it is not. I agree, RenderMan is very biased towards their micro-polygon renderers, but that doesn't mean it is not a giant step forward in some areas of the modeler/renderer interface. If you think about it (just step back for a second) almost all of the micro-polygon biased stuff is in the shading language. This is VERY unfortunate, becuase I think this is the most powerful part of the RenderMan interface. If you look at the geometric part of RenderMan, it is really just a very rich and flexible geometric description. I am not an expert on that part of RenderMan (I've been concentrating on the shading language), but I don't beleive there is anything earth shattering there. What is exciting is the shading language and its potential. >|> >|> Conceptually, Renderman seems to be designed like PostScript. >|> One renderman file, one image. While this works for the printed >|> page, animations and 3D graphics have continuity across frames >|> that RenderMan cannot describe or take advantage of. >I think Pixar has even made the comparison between RenderMan and PostScript >(notice the funny capitalization). And you're right, its pretty >useless for nice things like interfrace coherency. >|> Renderman is also grossly inefficient for representing >|> polygons, as it takes a [vertex, vertex, vertex, close] form for >|> representing each face instead of a list of verteces and then a >|> face list. >But its still O(n) space :-) Now guys, this just ain't true. The RiPointsPolygon C binding takes a list of vertices and a list of indexes into the vertex list to form the polygons. Check out pages 80-83 of ``The RenderMan Companion''. >|> Finally the concept of an actor/object is non-existant >|> in RenderMan. There is no grouping of faces with different >|> properties or relationships defined. >Maybe in RIB, but the C protocol is pretty PHIGS-like in its >structure. Of course, PHIGS is hardly an example of a >sophisticated, actor or object based environment. Like I said, I'm really a rookie at the geometric part or RenderMan. In fact, just reading these messages made me go take a look at the RIB stuff. Lo and behold, its true, there is no for loops or such in RIB. It is purely a geometry description. Oh well, can't have everything .... The C binding is much more powerful than plain RIB though Also, I'm not an expert in animation, and I don't really know what an ``actor'' is (although an intelligent guess may be close 8-). RenderMan does make an attempt at addressing animation (RiFrameBegin/RiFrameEnd pairs), but I don't know that that was its intended strong point, so I will beleive you that it is weak in that area. >|> While one could take one's own model from another system >|> and extract the Renderman Commands for it, it does not seem >|> possible to go the other way. Witness all the modeling programs >|> that support the RenderMan interface, but use their own >|> formats for working data (scene and objects). [all of them!] >Yes, it would be like converting PostScript to some other >vector drawing format. In general, it isn't possible without >loss of a lot of information. True in a sense. That is, if format A is a polygon only format, then it is possible to convert from RenderMan to format A, but probably not back again. Of course, that is always true of a richer format being converted to a simpler form. >|> PLEASE SOMEONE! Work on a scene description file format >|> that will describe an animation or scene, not just the >|> resultant list of polygons. >|> >|> My proposal: >|> One object format that includes geometry primatives >|> and surface descriptions. >|> One model format that describes position and motion >|> of objects in a scene. >|> Extentions to both for specific shading and >|> (for ray tracing) geometry organization (bounding boxes...). >My opinion: A scene description broken down into Modeling, >Animation, and Rendering components (what you have suggested) >is woefully inadequate. Suppose your constructive solid geometry >objects change over time? Maybe your surface attributes do, too. >Perhaps you want animated deformations. In short, nontrivial >scenes will require a richer environment than Model - Animate - Render. >M-A-R is certainly the traditional graphics pipeline, but it is not >the way to go for anything more than flying logos. >|> >|> John D. Woolverton, Video Bits >|> woolstar@cobalt.caltech.edu >Brook >-- >Brook Conner | Klacktoveedsedstene >Brown Computer Graphics | Fortune sez: Brook's Law -- Adding manpower to a late >dbc@cs.brown.edu | software project makes it later >uunet!brunix!dbc dbc@browncs.bitnet Box 1910 Brown U Prov RI 02912 After my defense of RenderMan, I'll end by saying that I don't think it is good enough either. I beleive Brook and John in their claims that it is lacking in animation support, but I don't beleive that that was its intended purpose anyway. I beleive Pixar itself uses other tools (both home brewed and commercial) to do its animations. I may be wrong, but I doubt it. I also agree that RenderMan is too micro-polygon biased in the shading language area. It is relatively easy to implement most shading techniques supported by RenderMan with micro-polygons, while many are very difficult to implement with other rendering techniques (ray tracing/radiosity). Anyway, back to work.... 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-)