Article View: comp.sys.next.misc
Article #1649Re: OpenGL vs. Renderman
From: Michael B. Johnson
Date: Thu, 16 Apr 1992 02:38
Date: Thu, 16 Apr 1992 02:38
135 lines
8339 bytes
8339 bytes
Anthony Berno writes > > In light of the release of 3.0 with bundled Renderman being just a few > months away, it is interesting to note that in a recent issue of Computer > Graphics World that the closing column discusses Silicon Graphics' > licensing of OpenGL, a derivative of the Iris GL, to other OS vendors. > > The column discusses a few other graphics systems, such as PHIGS et al. > and comes to the definite conclusion that OpenGL will be THE standard for > high end graphics starting NOW, and that it is the BEST of all of them. > > Has NeXT made a critical mistake in going with Renderman? Is the NeXT, in > the wake of this possible sweep of graphics systems, going to be left in > the dust with yet another fundamental incompatibility? I thought that > Renderman would, in only a few years, propel NeXT into the front ranks of > 3D graphics / CAD / animation. Now I'm not so sure. > > Comments? > This is an interesting question -- one that I've been thinking about off and on for the last year. I still don't have a definitive answer. I'll just raise a few interesting points for people who aren't real familiar with GL and RenderMan. First of all, computer graphics can be broken down into three main areas: modeling, animation, and rendering. - Modeling is the process of mathematically describing the properties of a given graphical entity. Points, vertices, connectivity, patch properties, color, material, etc. - Animation is the process of changing your model over time. This can include changing the position, shape, shading characteristics, etc. - Rendering, finally, is taking the model for each frame and generating the pixel data representing the scene. GL, now called OpenGL, also (I believe) GL 5.0, is the latest and greatest version of Silicon Graphics "Graphics Library". Graphics weenies like GL a lot because it lets them, as I like to think of it, "scrape their fingers on the metal" (or silicon, in this case). GL is feature rich and offers function calls for most everything you need to do way spiffy, way fast graphics. Theoretically, it's portable among all SGI platforms, but in reality, you can paint yourself in a corner quickly. GL suffers from the fact that it's a graphics library written for graphics hackers by graphics hackers. No one from SGI would ever insult anyone's intelligence by claiming that GL was any sort of object oriented approach to graphics. To write a program in GL is somewhat similar to writing a program on the Mac. You learn as many calls as you can, then you contact your friend who already writes software for the platform, get a skeleton of code from them, and modify to suit your needs. You rarely write a reasonable useful program using GL from scratch. With the upcoming Scenario package, which is SGI's object oriented layer on top of GL, many of the programming issues might go away, but I'm not sure of Scenario's relationship to OpenGL. To begin the segue to RenderMan, it's important to realize that people who use SGI's for production work (pick your favorite production house, ILM, Pixar, PDI, Rhythm & Hues, MetroLight, etc.) never (or at least, very, very rarely) use GL output for final work. They all have their own software-only renderers which do the final rendering. They use GL to write programs which help them create models (the modelling phase I talked about above), choreagraph the motion of those models over time (the animation phase I talked about above), and finally they use GL to render their image quickly to the scene (the rendering phase I talked about). In all cases, when they are finally satisfied with the animation they've created, they use their own software renderer to render the final frames. So how does RenderMan fit in? Well first of all, a bit of history. A few years back, for various and sundry reasons, the folks at Pixar, with the help and advice of most everybody who is anybody in computer graphics, defined a "scene description language" called RenderMan. The basic idea of RenderMan was to define a language for modelling software to talk to rendering software concerning a photorealistic description of a scene. The idea was that if they were sucessful, people could sell renderers that understood this language, and then modellers would only need to speak one language - RenderMan. RenderMan included a really cool thing called a shading language, which was a little language (with a C-like syntax) that allowed you to write your own shaders. It's a little too complicated to go into here, but suffice it to say that much of the power of RenderMan is hidden in the shading language. It's important to make the distinction that Pixar defined the RenderMan interface, much as Adobe defined the Postscript interface. Additionally, Pixar sells a product (bundled in 3.0) called prman, or PhotoRealistic RenderMan. This is a renderer which conforms to all the required portions of the RenderMan interface. I believe their are other renderers out there which support a RenderMan interface, but don't know names off the top of my head. Note that this is exactly analogous to the fact that other vendors offer Postscript RIPs made by people other than Adobe. The important distinction to catch here is that gl is intended as a general purpose graphics library for doing fast graphics, but doesn't really have the hooks to do photorealistic rendering. As time goes on, the smart folks at SGI have been adding functionality to get gl to asymptotically approach photorealistic rendering, but it's certainly not there yet. RenderMan, on the other hand, was designed from the ground up to be a functional interface to a piece of software which, by definition, could photorealistically render a scene. With the advent of Interactive RenderMan (which, as you would imagine, was developed on an SGI written in GL), RenderMan is pushing down, asymptotically approaching doing fast graphics. The idea of NeXT's 3DKit, written by Dave Springer, is to hide much of the complexity of writing 3D applications on the NeXT. The good thing is that you get the power of RenderMan rendering pretty much for free. The bad part is that it (the realtime aspect of it) only commercially exists on the NeXT, and we're subject to NeXT's speeding its performance up. With GL, you have a much harder time writing software, but you have the ability to go from an Indigo (GL in software, a machine costs ~10K for a minimal usable system) all the way to a 4 processor, 2 pipeline SkyWriter (~450K, 1 million polys/sec per pipeline). I've been around SGI machines since 1987, but haven't hacked them anywhere near as much as coworkers. They like the power, like the flexibility. But there are gaps. Recently, some folks in my group were porting some software to our SkyWriter and found some obscure restrictions on texture maps. These sorts of restrictions don't exist with RenderMan, but Interactive RenderMan isn't available on the SkyWriter. I've been a fan of RenderMan since I saw the draft spec, and think NeXT did the right thing by hitching their wagon to it. GL is different, but it's hard to explain to non graphicists why. I think both of them have a place. Maybe now you can see why I'm still not sure about this stuff. It's a very confusing subject... Hope the above was informative. -- --> Michael B. Johnson --> MIT Media Lab -- Computer Graphics & Animation Group --> (617) 253-0663 -- wave@media-lab.media.mit.edu --> NeXT Mail accepted at wave@waits.media.mit.edu
Technical Details
Message-ID:
<1992Apr16.023803.27179@news.media.mit.edu>Path:
arc1-ca.pugleaf.net!sparky!uunet!think.com!rpi!gatech!rutgers!micro-heart-of-gold.mit.edu!news.media.mit.edu!newsReferences:
<1992Apr15.211445.16925@godel.questor.wimsey.bc.ca>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!think.com!rpi!gatech!rutgers!micro-heart-of-gold.mit.edu!news.media.mit.edu!news From: wave@waits.media.mit.edu (Michael B. Johnson) Newsgroups: comp.sys.next.misc Subject: Re: OpenGL vs. Renderman Message-ID: <1992Apr16.023803.27179@news.media.mit.edu> Date: 16 Apr 92 02:38:03 GMT References: <1992Apr15.211445.16925@godel.questor.wimsey.bc.ca> Sender: news@news.media.mit.edu (USENET News System) Organization: MIT Media Laboratory Lines: 135