david@mks.com (David Rowley) (04/30/91)
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.
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 ?
There could be the standard sort of NFF, Rayshade type primitives
(sphere, ellipsoid, cone, polygon, box, etc) with a set of filters
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.
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.
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.
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 ?
--
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.commsr@gator.cacs.usl.edu (Srinivas R. Manapragada) (04/30/91)
In article <1991Apr30.003612.16050@mks.com> 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. > >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 ? > ... >Does it make sense ? Anyone interested ? Yes it would be nice to have a standard. However it should be more expressive and powerful than the language of say rayshade, which allows hierarchical objects to be defined rather easily. However one should also have some kind of procedural features. For example say while describing a forest I should be able to define it as for(x = 0; x < 100; x++) for(y = 0; y < 100; y++) FirTree(x + dither(), y + dither()); where FirTree is the parameterized object and dither provides a small amount of +- deviation. Ofcourse the object need not have its position as a parameter since they may be more naturally handled by modelling transformations but it may be more important to parameterize by, say, the surface color, texture etc. Also very compact descriptions arise through the use of fractals, IFS's etc., I wonder if they can be pulled into the language. _Srini_
jk87377@cc.tut.fi (Juhana Kouhia) (04/30/91)
In article <30137@rouge.usl.edu> msr@gator.cacs.usl.edu (Srinivas R. Manapragada) writes: > >However one should also have some kind of procedural features. > > for(x = 0; x < 100; x++) > for(y = 0; y < 100; y++) > FirTree(x + dither(), y + dither()); Now the main algorithm for the ray tracers in the net is 1. build the scene 2. trace it I have designed my program so that I can generate the objects on the fly with the modelling language I have in the program. For example, if I have a crass field I can present it by program code, it takes a bit memory and is nearly as fast as if I store each crass to the memory; a large one memory. In the article John M. Snyder and Alan H. Barr, Ray Tracing Complex Models Containing Surface Tessellations, SIGGRAPH '87 Proceedings they made a large field by copying a small crass field part to the several places; of course you don't see the similarities easily, but if our field is not equally distributed it causes problems with the memory. >but it may be more important to parameterize by, say, the surface >color, texture etc. If you mean "sphere r g b texture pos_x pos_y pos_z"-type presentation I say no. It's much easier if every parameter is possible to replace by a small program - user can make that program too. RenderMan is good example. That all guess means that the program must be in object format not executable. Juhana Kouhia
bcorrie@csr (Brian Corrie) (04/30/91)
msr@gator.cacs.usl.edu (Srinivas R. Manapragada) writes: >In article <1991Apr30.003612.16050@mks.com> 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. >> >>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 ? >> ... >>Does it make sense ? Anyone interested ? >Yes it would be nice to have a standard. However it should be more expressive >and powerful than the language of say rayshade, which allows hierarchical >objects to be defined rather easily. However one should also have some kind of >procedural features. For example say while describing a forest I should be able >to define it as > for(x = 0; x < 100; x++) > for(y = 0; y < 100; y++) > FirTree(x + dither(), y + dither()); > > where FirTree is the parameterized object and dither provides a small >amount of +- deviation. Ofcourse the object need not have its position as a >parameter since they may be more naturally handled by modelling transformations >but it may be more important to parameterize by, say, the surface color, texture >etc. >Also very compact descriptions arise through the use of fractals, IFS's etc., I >wonder if they can be pulled into the language. >_Srini_ Makes wonderful sense. In fact, this is what the RenderMan Specification tries to do. Its definition contains a multitude of primitves, CSG, etc. etc. One could write a book on it.... Wait a second, there is a book on it 8-) Check out ``The RenderMan Companion'' by Steve Upstill. Its published by Addison Wesley and the ISBN number is 0-201-50868-0. A more technical document is available from PIXAR as well, giving the gory details of the interface. Note that ``The RenderMan Companion'' is a pretty good graphics text as well. It should be possible to do all of the above with the RenderMan Interface. 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-)
bcorrie@csr (Brian Corrie) (04/30/91)
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-)
yeidel@tomar.accs.wsu.edu (Joshua Yeidel) (05/01/91)
Isn't this approximately what RenderMan is trying to accomplish?
matt@mandala.think.com (Matt Fitzgibbon) (05/01/91)
In article <30137@rouge.usl.edu> msr@gator.cacs.usl.edu (Srinivas R. Manapragada) writes:
Yes it would be nice to have a standard. However it should be more
expressive
and powerful than the language of say rayshade, which allows hierarchical
objects to be defined rather easily. However one should also have some
kind of procedural features.
Rather than define another new language, has anyone explored using
Lisp or some subset as a geometric description language?
-Mattwoolstar@nntp-server.caltech.edu (John D. Woolverton) (05/01/91)
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. 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. 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. Finally the concept of an actor/object is non-existant in RenderMan. There is no grouping of faces with different properties or relationships defined. 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!] 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...). John D. Woolverton, Video Bits woolstar@cobalt.caltech.edu
will@rins.ryukoku.ac.jp (will) (05/01/91)
In article <MATT.91Apr30142917@mandala.think.com>, matt@mandala.think.com (Matt Fitzgibbon) writes: >Rather than define another new language, has anyone explored using >Lisp or some subset as a geometric description language? > If I remember correctly, SYMBOLICS Corp. uses just this technique. I think it was LISP based. I wonder, do they still exist? Anyone know? William Dee Rieken Researcher, Computer Visualization Faculty of Science and Technology Ryukoku University Seta, Otsu 520-21, Japan Tel: 0775-43-7418(direct) Fax: 0775-43-7749 will@rins.ryukoku.ac.jp
david@mks.com (David Rowley) (05/01/91)
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,
in a simple portable way. The standard should be able to be read on
even the smallest of machines, by the simplest of renderers. One
of the main reasons it seems that the teapot surfaces all over the
place is that it is one of the most readily available models, found
in a number of different formats. People should be able to trade
models in the same way people are currently trading 'GIF' images.
Is the RIB format simply a Renderman program compiled into a bytestream ?
If it is a reasonable subset, perhaps it could be used. Unfortunately
it is not documented (or even really discussed) in Upstill's Renderman
Companion.
I like the programmatic approach of Renderman, but the overhead of
interpretation just to get at the data is too high. The shader
language is particularly neat, and perhaps that is a reasonable
way to describe that portion. I'd like to see the programmatic
approach used at a higher level, to *create* scenes modeled in this
format. This means that the user of the data does not need to
understand the same programming language.
There is also Pixar's copyright limitations on Renderman that could cause
problems. They do license the interface without charge, but they
have the right to refuse to do so. Are they likely to approve a
public domain implementation ?
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.
David
--
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.comdbc@cs.brown.edu (Brook Conner) (05/01/91)
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. |> |> 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 :-) |> 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. |> 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. |> 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
stparker@uokmax.ecn.uoknor.edu (Steve Parker) (05/01/91)
woolstar@nntp-server.caltech.edu (John D. Woolverton) writes: > 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. > PLEASE SOMEONE! Work on a scene description file format >that will describe an animation or scene, not just the >resultant list of polygons. Well, I am not Mr. Computer Graphics expert yet, but I am working diligently on being one. For the last four months, I have been busily working on my own raytracing program. I have spent most of that time working on an input language. I find the same shortcomings in current file formats - They stink for animation. If I have a large scene, I want to read it in *once* and generate hundreds of views or variations of the one scene. Computers are getting fast enough to make ray traced animations even more feasible. With these observations, I set out to design my input language. I have come up with an interpretive type language which has proved to be very powerful and very expandable. At the bottom, I have attached a short piece of code which renders a CSG face. I would appreciate any inputs or *constructive* criticisms. Much of my language is incomplete, but some of the features which will be implemented include: - if else contstructs - for and while loops - Object copying. - Default object values - Object paths and camera paths - for motion blur - Built in matrix and vector manipulation One feature that I like is that I can add a primitive without changing the yacc or lex code. I simply put the name of the new primitive in a file, write all of the associated routines, add it to the Makefile and type make. The language is really powerful in my opinion, but what do I know? I do not want to bore the entire group with the gory details, but I can supply more information if anyone would like it. Again, I would appreciate any input. Steve Parker sgp@phyast.nhn.uoknor.edu /* * render a CSG face */ /* * Note: the names light1, light2, and light3 are not special, they * are simply variable names which are assigned to the lights. * They could have just as easily been Larry, Curly and Moe. */ light1=light_source(POSITION={0,-10,30},BRIGHTNESS=1,COLOR=[1,1,1],TYPE=Point); light2=light_source(POSITION={0,-10,-10},BRIGHTNESS=.8,COLOR=[1,1,1],TYPE=Point); light3=light_source(POSITION={0,-1000,0},BRIGHTNESS=.8,COLOR=[1,1,1],TYPE=Point); lighting(SOURCE=light1,SOURCE=light2,SOURCE=light3); /* * The idea behind these is that they will be pretty much the same for * most cameras * */ params=parameter(SUPERSAMPLING=Jittered, SAMPLES=1, MAX_RAYTREE_DEPTH=4, CUTOFF_THRESHOLD=.001, SHADOWS=True); camera1=camera(EYE_POINT={1,-4,0},LOOK_POINT={0,0,0},UP_VECTOR={0,0,1}, FOV=45, XRESOLUTION=250, YRESOLUTION=250, XOUTPUT=True, TITLE="Michele's Face", OUTFILE="face.rle",PARAMETERS=params); /* * Set up surfaces */ mouthsurf=surface(AMBIENT=[.01,.01,.01],DIFFUSE=[.8,.01,.01],SPECULAR=[.9,.9,.9], SR_COEFF=25, REFLECTIVITY=.7, TRANSPARENCY=0); nosesurf=surface(AMBIENT=[.01,.01,.01],DIFFUSE=[.7,0,.5],SPECULAR=[.9,.9,.9], SR_COEFF=25, REFLECTIVITY=.9, TRANSPARENCY=0); eyesurf=surface(AMBIENT=[.01,.01,.01],DIFFUSE=[.5,.3,.9],SPECULAR=[.9,.9,.9], SR_COEFF=25, REFLECTIVITY=.6, TRANSPARENCY=0); facesurf=surface(AMBIENT=[.01,.01,.01],DIFFUSE=[.9,.7,.5],SPECULAR=[.9,.9,.9], SR_COEFF=25, REFLECTIVITY=.4, TRANSPARENCY=0); hairsurf=surface(AMBIENT=[0,0,0],DIFFUSE=[.5,.5,.5],SPECULAR=[0,0,0], SR_COEFF=25, REFLECTIVITY=.1, TRANSPARENCY=0); /* * Create the primitives. Again face, left_eye, right_eye, etc. are * just variable names * */ face=sphere(POSITION={0,0,0},RADIUS=1.2, SURFACE=facesurf); left_eye=sphere(POSITION={-.5,-.8,.6},RADIUS=.3,SURFACE=eyesurf); right_eye=sphere(POSITION={.5,-.8,.6},RADIUS=.3,SURFACE=eyesurf); left_nose=sphere(POSITION={-.2,-.95,0},RADIUS=.4,SURFACE=nosesurf); right_nose=sphere(POSITION={.2,-.95,0},RADIUS=.4,SURFACE=nosesurf); mouth_top=sphere(POSITION={0,-1.32,.15},RADIUS=1,SURFACE=mouthsurf); mouth_bot=sphere(POSITION={0,-.82,-.1},RADIUS=.8,SURFACE=mouthsurf); /* * CSG operations */ eyes=left_eye+right_eye; nose=left_nose&right_nose; mouth=mouth_bot-mouth_top; /* * A background color may also be specified here */ world(OBJECT=(face-eyes)+(mouth+nose)); /* * Render the image */ render(CAMERA=camera1); /* And we could then continue and render another view, add objects, or * just render something else completely different altogether */
bcorrie@csr (Brian Corrie) (05/02/91)
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-)
bcorrie@csr (Brian Corrie) (05/02/91)
david@mks.com (David Rowley) writes: >Many people have suggested Renderman as being ``the answer''. I don't think it is ``the answer'', but it is a step forward. See my post just before (or after, depending on mailers of course) this one for a discussion of some of the faults/omissions of RenderMan. >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, >in a simple portable way. The standard should be able to be read on >even the smallest of machines, by the simplest of renderers. One >of the main reasons it seems that the teapot surfaces all over the >place is that it is one of the most readily available models, found >in a number of different formats. People should be able to trade >models in the same way people are currently trading 'GIF' images. >Is the RIB format simply a Renderman program compiled into a bytestream ? >If it is a reasonable subset, perhaps it could be used. Unfortunately >it is not documented (or even really discussed) in Upstill's Renderman >Companion. From what I understand, the RIB format is just a scene description, without all of the control flow and other constructs of the C binding. It is still quite rich geometrically, so you are right, most PD type renderers will not be able (mine included 8-) to handle most of the more sophisticated primtives. Unfortunate, but NURBS and CSG are the best ways to describe many objects. Polygons just don't cut it for a lot of things. >I like the programmatic approach of Renderman, but the overhead of >interpretation just to get at the data is too high. The shader >language is particularly neat, and perhaps that is a reasonable >way to describe that portion. I'd like to see the programmatic >approach used at a higher level, to *create* scenes modeled in this >format. This means that the user of the data does not need to >understand the same programming language. I agree. I actually thought RIB had the programming constructs as well, until recently. Without them RIB is JAF (Just Another Format 8-), rich as it may be. One thing I just realized: if we loose the programming constructs of the C binding, the RiPointsPolygon mentioned in my previous posting isn't nearly as efficient as it could be. Only duplicate vertices within one polyhedra are avaoided. Better than nothing, but still, it would be nice if RIB could have variables as well, no? >There is also Pixar's copyright limitations on Renderman that could cause >problems. They do license the interface without charge, but they >have the right to refuse to do so. Are they likely to approve a >public domain implementation ? This I'm not too sure about. Any comments from people out there that have dealt with licensing from Pixar. Anyone form Pixar have any comments. >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. >David >-- > 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 Later, 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-)
jamison@boulder.ColoState.EDU (Jamie Gulden) (05/02/91)
In article <1991Apr30.003612.16050@mks.com> david@mks.com (David Rowley) writes: >One reason for this is >the lack of a standard modelling format. > >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 ? > Take a look at the renderman interface specification. Thats basically what it was designed for.
gritz@seas.gwu.edu (Larry Gritz) (05/02/91)
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. > Not only is RenderMan perfectly acceptable for describing scenes to a renderer which uses ray tracing, but RenderMan supports features which are not possible on ray tracers at all (e.g. Displacement shaders). I wonder exactly which features you want that cannot be described in RenderMan? Don't forget the explicit "trace" command in the shading language. > 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. Not true at all. See RiPointsPolygons and RiGeneralPointsPolygons. > Finally the concept of an actor/object is non-existant >in RenderMan. This is because RenderMan is designed to be an interface to a renderer, not a way to specify models or animation scripts. > > John D. Woolverton, Video Bits > woolstar@cobalt.caltech.edu ------------------------------------------------------------------------ Larry Gritz lg@galileo.usno.navy.mil US Naval Observatory 202-653-1034 Washington, DC 20392-5100 also: gritz@seas.gwu.edu ------------------------------------------------------------------------
dean@cs.mcgill.ca (Dean NEWTON) (05/02/91)
In article <MATT.91Apr30142917@mandala.think.com> matt@mandala.think.com (Matt Fitzgibbon) writes: >In article <30137@rouge.usl.edu> msr@gator.cacs.usl.edu (Srinivas R. Manapragada) writes: > > Yes it would be nice to have a standard. However it should be more > expressive > and powerful than the language of say rayshade, which allows hierarchical > objects to be defined rather easily. However one should also have some > kind of procedural features. > >Rather than define another new language, has anyone explored using >Lisp or some subset as a geometric description language? > You may want to consider using scheme for this purpose. I have appended a brief description of the Elk (Extension Language Kit) scheme interpreter at the end of this message. Since scheme is a general-purpose interpreted language, embedding Elk into your system not only gives you a language for storing scenes, but you also get: -- an interpreted command language -- a cleaner (than the C binding) interface to Xlib/Xt/Motif -- an interpreter to Xlib/Xt/Motif In fact, this will completely eliminate the dichotomy between "scene description files" and "programs". Elk is available for anonymous ftp from export.lcs.mit.edu Enjoy, Kaveh Kardan Taarna Systems, Inc. Montreal Quebec Canada (posting from a friend's account) ---------------------------------------------------------------------------- Implementation: Elk Implemented by: Oliver Laumann <net@tub.UUCP> <net@tub.BITNET> Hardware: VAX, Sun-3, Sun-4, ISI 680x0, Intel 80386, Mips, IBM/RT, and others Operating Systems: UNIX/SunOS/Ultrix Price/Availability: Free. Available as source code through the usual sources archives and by e-mail from the author Intended Use: Primarily as a general extension language Elk (Extension Language Kit) is a Scheme interpreter intended to be used as a general extension language; it is also useful as a stand-alone implementation of Scheme. One purpose of the Elk project is to end the recent proliferation of mutually incompatible Lisp-like extension languages. Instead of inventing and implementing yet another extension language, application programmers can link the Scheme interpreter into their application in order to make it extensible and highly customizable. The Elk project was started in 1987 to support ISOTEXT, an ODA-based document system (a WYSIWYG editor) that is being developed at the Technical University of Berlin. Elk has been successfully demonstrated as the extension language kernel of ISOTEXT, e.g. at the Hanover Fair 1989. The Elk Scheme interpreter is R^3RS compatible (with some minor exceptions listed in a separate document); future releases will conform to the R^4RS and/or P1178 as soon as the respective standards become available. Non-standard features of the Scheme implementation include: o dynamic loading of object files o creation of an executable image from the running interpreter (``unexec'') o a macro facility o environments as first-class objects o dynamic-wind, fluid-let o autoloading, provide/require The Scheme interpreter can easily be extended by application-specific new types and primitive procedures. Such extensions are typically written in C or C++ and dynamically loaded into the running interpreter. The current release of Elk includes several such extensions, e.g. interfaces to the X11 Xlib and to the application programmer interface of the Xt intrinsics, and interfaces to the Athena, HP, and Motif widget sets.
turk@Apple.COM (Ken "Turk" Turkowski) (05/02/91)
The problem with a procedural language (like PostScript) is that the definition of the language specifies exactly how the picture is to be rendered. Procedural languages generally require a complex parser that is really a compiler that builds expression trees, etc. A declarative language does not have programming constructs, and merely describes the scene. While there are certain universally understood data types, it is up to the implementation to determine exactly what the resultant picture looks like (i.e. wireframe, anti-aliased, gouraud-shaded, light transport global illumination, etc.). If you want a programming language, use C; you'll be satisfied with nothing less! -- Ken Turkowski @ Apple Computer, Inc., Cupertino, CA Internet: turk@apple.com Applelink: TURK UUCP: sun!apple!turk
raisa@hila.hut.fi (Olli R{is{) (05/02/91)
bcorrie@csr (Brian Corrie) writes: >>Is the RIB format simply a Renderman program compiled into a bytestream? >From what I understand, the RIB format is just a scene description, without >all of the control flow and other constructs of the C binding. As far as I know, a RIB file resembles the C interface, but all parameters to RenderMan functions are literals. Variables don't exist -- nor are there any C other language constructs. You could produce a RIB file from a C language scene description by linking it with a "renderer" that outputs a function name and its arguments for each RenderMan function call. >>There is also Pixar's copyright limitations on Renderman that could cause >>problems. >This I'm not too sure about. Any comments from people out there that have >dealt with licensing from Pixar. Anyone form Pixar have any comments. Some time ago, someone from UK told us (here in comp.graphics) that it is virtually impossible to get any answers from Pixar. However, if you are going to write a RenderMan-compatible modeller or renderer, you are supposed to inform Pixar about it. I think you are very welcome to write a modelling program, but (if I read correctly between the lines of the RenderMan specifications) the rendering part could cause problems -- you would be competing with Pixar. Olli Raisa
jk87377@cc.tut.fi (Juhana Kouhia) (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''. How about Thalmann & Magnanet-Thalmann animation language? I have not read much about it, so I'm wondering if anyone could make a summary about it. What it can do? What is the difference between T&M-T language and RenderMan? Etc. Juhana Kouhia
david@mks.com (David Rowley) (05/02/91)
In article <bcorrie.673121202@csr> bcorrie@csr (Brian Corrie) writes: >david@mks.com (David Rowley) writes: > >>Is the RIB format simply a Renderman program compiled into a bytestream ? >>If it is a reasonable subset, perhaps it could be used. Unfortunately >>it is not documented (or even really discussed) in Upstill's Renderman >>Companion. > >From what I understand, the RIB format is just a scene description, without >all of the control flow and other constructs of the C binding. It is still >quite rich geometrically, so you are right, most PD type renderers will not >be able (mine included 8-) to handle most of the more sophisticated primtives. >Unfortunate, but NURBS and CSG are the best ways to describe many objects. >Polygons just don't cut it for a lot of things. Where can I get a description of the RIB format ? It could be used as a standard format, since RenderMan is likely to be fairly popular. Like it or not. A RIB translator could transform the more complicated RIB primitives into simpler ones that all renderers could understand. (polygons, triangles, whatever). >I agree. I actually thought RIB had the programming constructs as well, until >recently. Without them RIB is JAF (Just Another Format 8-), rich as it may >be. Although it's just another format, it has some high-powered backing, and isn't likely to go away any day soon. >>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. Someone pointed me to P3D from Pittsburgh Supercomputing Center, which is based on a simple lisp interpreter. It comes close, but I still think a programmatic approach embedded within the scene description language is a liability. Programs should be used to *generate* this stuff. The reason I like the lisp-style *syntax* is that it is easy to parse. -- 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
rick@pangea.Stanford.EDU (Rick Ottolini) (05/02/91)
In article <1991May1.161329.26495@uokmax.ecn.uoknor.edu> stparker@uokmax.ecn.uoknor.edu (Steve Parker) writes: > With these observations, I set out to design my input language. >I have come up with an interpretive type language which has proved to >be very powerful and very expandable. At the bottom, I have attached >a short piece of code which renders a CSG face. I would appreciate any >inputs or *constructive* criticisms. An example of a declarative binding to the RenderMan specification is the scene description language in the ART part of SunVision. I did not see a declarative binding or metafile description to RenderMan in Upstill's book. I wrote a declarative scene description language for the purposes of scientific visualization a few years ago. The goal was to represent discrete data as 3-D geometric objects. (Continuous samplings in 1-D, 2-D, and 3-D have their own representation techniques such as graphs, surfaces, and volumes.) I got tired of writing large amounts of generally repetitive PHIGS code and of the slow edit-compile-run-debug cycle method of building scenes. I modeled my scene description language after the [unpublished] metafile of MacDraw. The characteristics Iemulated from MacDraw was a rich set of primitive objects, from zero to three dimensions and the method of compositing into complex objects. I also added a large set of object attributes, generally most of the rendering capabilities of the PHIGS variants I was using. The graphics shops that sell turn-key 3-D design systems at graphics trade shows may have some very good scene description languages. I haven't done a systematic study of their products, but perhaps someone else in this newsgroup could report on this.
bouma@cs.purdue.EDU (William J. Bouma) (05/03/91)
In article <13281@goofy.Apple.COM> turk@Apple.COM (Ken "Turk" Turkowski) writes: >The problem with a procedural language (like PostScript) is that >the definition of the language specifies exactly how the picture >is to be rendered. Procedural languages generally require a complex >parser that is really a compiler that builds expression trees, etc. In the case of PostScript this is just not true! PostScript does not require ANY parsing. If this shocks you try doing some reading on the subject of "Threaded Interpreters". I have written a TI based animation tool. It was very easy to write and it is flexible to do whatever I may want. The reason I wrote it was I wanted an interactive graphics environment on this HP I was using. I got tired of the awkward compile-load-run cycle that the C language requires. -- Bill <bouma@cs.purdue.edu>
david@mks.com (David Rowley) (05/03/91)
In article <14567@medusa.cs.purdue.edu> bouma@cs.purdue.EDU (William J. Bouma) writes: >In article <13281@goofy.Apple.COM> turk@Apple.COM (Ken "Turk" Turkowski) writes: >>The problem with a procedural language (like PostScript) is that >>the definition of the language specifies exactly how the picture >>is to be rendered. Procedural languages generally require a complex >>parser that is really a compiler that builds expression trees, etc. > > In the case of PostScript this is just not true! PostScript does not > require ANY parsing. If this shocks you try doing some reading on > the subject of "Threaded Interpreters". I took the postscript interpreter part of GNU's Ghostscript, and hacked up an interface for Rayshade. It was kind of neat, though the Ghostscript code is pretty hard to use. Saying that postscript doesn't need parsing is too kind. I'd more agree with the simpler, original Threaded Language, Forth. The bottom line is that a renderer should deal with rendering type concerns. A language only benefits the builder of the scenes, not the renderer, thus it can safely be extracted. The following pipeline seems reasonable: Animation, ---> Standard Scene ---> Simplification -> Render Programmatic Format, Filters Scene Description Camera, Lights Where the simplification filters would convert the scene description into the level of simplicity required by the particular renderer. > I have written a TI based animation tool. It was very easy to write > and it is flexible to do whatever I may want. The reason I wrote it > was I wanted an interactive graphics environment on this HP I was > using. I got tired of the awkward compile-load-run cycle that the C > language requires. >-- >Bill <bouma@cs.purdue.edu> -- 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
craig@weedeater.math.yale.edu (Craig Kolb) (05/03/91)
In article <MATT.91Apr30142917@mandala.think.com>, matt@mandala.think.com (Matt Fitzgibbon) writes: >Rather than define another new language, has anyone explored using >Lisp or some subset as a geometric description language? Enclosed is an annoucement for the Pittsburgh Supercomputing Center's P3D, which "uses lisp with slight extensions to store three-dimensional models". I've yet to look at P3D myself, but it may be relevant to this disucssion. Craig --- PSC P3D VERSION 2.0 AVAILABLE ----------------------------- The third release of the Pittsburgh Supercomputing Center's P3D software is now available. This software uses lisp with slight extensions to store three-dimensional models; we are using it as the standard format for 3D models within the PSC. A simple lisp interpreter is included with the P3D release, so there is no need to have access to any vendor's lisp to run this software. The copyright to the P3D software is owned by Carnegie Mellon University, of which the Pittsburgh Supercomputing Center is a department. We copyright it so that no one can grab it and market it as their own. Feel free to copy it and distribute it around your own site, and to modify it. We ask that you do not redistribute it, as we want new users to get it from us so we can keep track of it and maintain a mailing list. If you have modifications to the code or bug reports, or would like to arrange to redistribute it, please contact us. This code is provided 'as is' without expressed or implied warranty; the PSC makes no representations about its suitability for any particular purpose. HIGHLIGHTS The highlights of the new release are the mouse-driven user interfaces for Motif, Open Look, and Silicon Graphics GL, and the DrawP3D subroutine library for generating P3D without ever looking at the underlying Lisp. Renderer interfaces have been added for generic, DEC, and Sun Phigs, and version 3.0 of Craig Kolb's Rayshade ray tracer. We have also installed a new parser, which should be more robust and provide better diagnostics on P3D files containing Lisp errors. It also will allow the rendering of larger models on some platforms. RENDERERS The PSC P3D software currently supports seven renderers. They are: Painter, a Painter's Algorithm renderer. This runs on just about everything, but requires the PSC's DrawCGM library and can only draw flat-shaded polygons. If you need the DrawCGM library, get the GPlot software distribution by anonymous FTP from calpe.psc.edu, in the directory pub/gplot. Dore renderer, which is an interface to the Stardent Inc. Dore renderer software. This is the recommended renderer for Stardent workstations. Silicon Graphics Inc. GL language renderer interface. This is the recommended renderer for SGI workstations and IBM R6000 workstations. Generic Phigs renderer interface. This renderer should work with only minor modification on any implementation of Phigs, but because (like generic Phigs) it does not handle light sources it is not the recommended renderer on any platform. Sun Phigs+ renderer interface. This renderer should work with Sun Phigs. It produces excellent results with Sun hardware with graphics accelerators and a 24 bit display, but because of limitations with some versions of the Sun Phigs software it may not work properly on platforms with 8 bit displays. Try this renderer if you have a Sun platform, and if you don't like the results, switch to the Painter renderer. DEC Phigs+ renderer interface. This renderer should work with DEC Phigs. It is the recommended renderer for DEC platforms with 24 bit displays and graphics accelerators, for example accelerated DECStation 5000's. For 8 bit DECStations, one might want to try both this renderer and the Painter renderer. Rayshade ray tracer renderer interface. This renderer is an interface to Craig Kolb and associates' Rayshade ray tracer (version 3.0, patch level 5). It produces some very nice images, very slowly. The current implementation is a first release of the interaface and does not properly support all P3D model elements (for example, text primitives and vertex colors). GETTING THE CODE The code is available via anonymous FTP from the machine calpe.psc.edu. If you do not already have the PSC's GPlot and DrawCGM software, you can get that also from the same machine. (You will need GPlot/DrawCGM if you are using the Painter renderer, which is the recommended renderer on machines lacking special 3D graphics hardware). To install the software on a Unix system, do the following: - FTP to calpe.psc.edu (internet address 128.182.66.148). - Log in as anonymous, with your name as password. - cd to the directory pub/p3d (the GPlot software is in pub/gplot). - Set file transfer mode to Binary or Image. - Get p3d_2_0.tar.Z, (or p3d_2_0.tar if your machine doesn't have the 'uncompress' utility). - Move the tar file to an otherwise empty directory on your machine. - Uncompress the tar file with the command 'uncompress p3d_2_0.tar'. If this doesn't work, you should have gotten the uncompressed version; see above. - Extract the contents of the tar file with the command 'tar -xvf p3d_2_0.tar' . - Follow the directions in the README file contained in the tar file. To install the software on a VMS system, do the following: - FTP to calpe.psc.edu (internet address 128.182.66.148). - Log in as anonymous, with your name as password. - cd to the directory pub/p3d (the GPlot software is in pub/gplot). - Get tar2vms.c, a freely distributable tool copyrighted by Sid Penstone, Dept. of Electrical Engineering, Queen's University, Kingston, Ontario, Canada K7L3N6. - Set file transfer mode to Binary or Image. - Get p3d_2_0.tar, giving it the local name p3d_2_0.tar . - Move the tar file and tar2vms.c to an otherwise empty directory on your machine. - Compile and link tar2vms.c. It's a stand-alone program needing no libraries except the usual sys$library:vaxcrtl.olb. - Give the following commands to unpack the tar file: $ assign p3d_1_1.tar tape $ tar2vms:== $dev:[directory]tar2vms.exe (where dev and directory are your current default device and directory). $ tar2vms xv - Follow the directions in the README file contained within the tar file. ------ NOTE: The Motif and Open Look user interfaces in this release require a bugfix to the PSC's GPlot/DrawCGM software which is not yet in the released version (as of March 14, 1991; the release is expected before the end of March). The symptom of the problem which this fixes is incorrect color map handling using these user interfaces. The fix is to relink DrawCGM with the version of xws_color.c in the pub/p3d anonymous FTP directory on calpe.psc.edu, or to include that module in the linking of the P3D executables. ------ If you get this software, please send your name and network address to me at welling@seurat.psc.edu so that we can send you announcements of updates and bug fixes. If you find bugs, that is also the address to which to send the bug reports. -Joel Welling Pittsburgh Supercomputing Center welling@seurat.psc.edu (412)268-6352
bcorrie@csr (Brian Corrie) (05/03/91)
david@mks.com (David Rowley) writes: <STUFF DELETED? > Where can I get a description of the RIB format ? It could > be used as a standard format, since RenderMan is likely to > be fairly popular. Like it or not. A RIB translator > could transform the more complicated RIB primitives into > simpler ones that all renderers could understand. > (polygons, triangles, whatever). The address I have for Pixar is: PIXAR 3240 Kerner Boulevard San Rafael CA 94901-9905 Unfortunately, I seem to remember hearing that they have moved recently. Anyone know the scoop on this? The RIB format is described in a document called ``The RenderMan Interface''. I have version 3.1, from Spetember 1989. I don't know if there are newer ones or not. I am posting this rather than emailing, because I have received a couple of requests, and there are probably others that are interested. Be warned, it costs some money, but not very much... ($25 dollars or so I think). 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-)
adrianho@barkley.berkeley.edu (Adrian J Ho) (05/05/91)
In article <1991May3.160108.26438@cs.yale.edu> craig@weedeater.math.yale.edu (Craig Kolb) writes: [ most of P3D announcement deleted, except ] > - FTP to calpe.psc.edu (internet address 128.182.66.148). That's 128.182.62.148 (at least of 5/4/91). ^^
pcb@basin06.cacs.usl.edu (Peter C. Bahrs) (05/06/91)
In article <30137@rouge.usl.edu> msr@gator.cacs.usl.edu (Srinivas R. Manapragada) writes: >In article <1991Apr30.003612.16050@mks.com> 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. >> >>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 ? >> ... >>Does it make sense ? Anyone interested ? > >Yes it would be nice to have a standard. However it should be more expressive >and powerful than the language of say rayshade, which allows hierarchical >objects to be defined rather easily. However one should also have some kind of >procedural features. For example say while describing a forest I should be able >to define it as I just finished a dissertation that proposes an object-oriented framework for concurrent graphics in heterogeneous environments. In particular, the modeling primitives, messaging protocols, and Scene composition are presented. The oo approach accomplishes (by far) modeling facilities found in PHIGS and HOOPS but adds some really neat capabilities, like the ability to model with high level primitives (and user defined primitives) and have the renderer (camera) break the objects into primitives into those tailored for a specific platform. I can't post the dissertation (260 pages) but it is going to UMI now and will be in our library next month. Title: AN OBJECT-ORIENTED FRAMEWORK FOR CONCURRENT GRAPHICS IN HETEROGENEOUS ENVIRONMENTS (we call the prototype "GO||" for concurrent graphics objects) The first paper will appear in an oo graphics edited series book by John Wiley, due out Fall 91. /*----------- Thanks in advance... --------------------------------------+ | Peter C. Bahrs | | The USL-NASA Project | | Center For Advanced Computer Studies INET: pcb@swamp.cacs.usl.edu | | 2 Rex Street | | University of Southwestern Louisiana ...!uunet!dalsqnt!gator!pcb | | Lafayette, LA 70504 | +-----------------------------------------------------------------------*/
graeme@labtam.labtam.oz (Graeme Gill) (05/06/91)
In article <1991May2.134020.4952@cc.tut.fi>, jk87377@cc.tut.fi (Juhana Kouhia) writes: > > How about Thalmann & Magnanet-Thalmann animation language? > I have not read much about it, so I'm wondering if anyone could make a > summary about it. The following info is from the book: Nadia Magnenat-Thalmann, Daniel Thalmann,"Image Synthesis: Theory and Practice", Computer Science Workbench, Editor: Tosiyasu L. Kunii, Springer-Verlag, ISBN 0-387-70023-4 MIRALab is the image synthesis and computing laboratory of the University of Montreal. Two types of software have been produced: Research and development tools: MIRA-SHADING, the main language for synthesis and animation of realistic images. CINEMIRA-2, an animation sub-language. INTERMIRA, a specification language for interactive image synthesis and animation systems. EXPERTMIRA, an Artificial Intelligence language for the development of expert systems in image synthesis and animation. User-friendly systems: The MIRANIM director oriented system, an advanced actor based animation system. The SABRINA image synthesis system. The MUTAN multiple track animator system for motion synchronization. The HUMAN FACTORY system, an animation system for articulated bodies. A description of the SABRINA image synthesis system is given in the book as well as a look at some of the other systems listed above. References are given to more detailed descriptions. The book came with an insert with the following on it: More information about the MIRALab Image Synthesis System SABRINA is available upon request. Manuals and software for D.E.C. VAX VMS systems can be ordered at the following address: N. Magnenat-Thalmann HEC, Universite de Montreal 5255 avenue Decelles Montreal, P.Q. Canada, H3T 1V6 For those interested in this book, here is some of the preface: Image Synthesis: Theory and Practice is the first book completely dedicated to the numerous techniques of image synthesis. The book contains a detailed description of the most important algorithms; other algorithms are summarized or simply listed. > What it can do? What is the difference between T&M-T > language and RenderMan? Etc. I am not familiar enough with any of these languages to give a definitive answer to this question. However, these tools seem to be complete enough that some spectacular animations have been generated with them. The most well known is probably "Rendez-vous a Montreal". Graeme Gill Labtam Australia
thomsen@spf.trw.com (Mark R. Thomsen) (05/07/91)
In article <1991Apr30.211131.7166@nntp-server.caltech.edu> woolstar@nntp-server.caltech.edu (John D. Woolverton) writes: > 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. > > One model format that describes position and motion > of objects in a scene. With some stuff edited out. I wonder, in light of these comments, what NeXT and Pixar have done to produce Interactive RenderMan? NeXT worked with Adobe to move PostScript to Display PostScript. Some of the obvious issues were addressed or ignored, but it was one stab at moving a static description language into a more complex and dynamic interface. I would anticipate that Interactive RenderMan addressed some of the obvious issues. Comments? Does anyone know status and specifications of IRM? Mark R. Thomsen
thinman@netcom.COM (Lance Norskog) (05/07/91)
Well, a picture standard is a first step. But, I don't want to look at pictures created by others, I want to interact with them. I've designed a first cut at a 3D real-time window system, called 5D. The visual part is 3 dimensions, real-time interaction gives the fourth dimension, and sound and other interaction (such as force-feedback joysticks) form the fifth dimension. 5D uses a Smalltalk-style object-oriented system to define visual objects and their static and dynamic properties: a box may be blue, shiny, and have a sound inside it which gets louder when you get near. Adding specifications for rendering via this or that method is a minor detail under this method. The system can support still-frame or continuous motion, depending on how much rendering you're willing to implement and wait around for. The specification is available by e-mail. It is 60 pages of nroff-d output. Lance Norskog thinman@netcom.com
cn09+@andrew.cmu.edu (Christopher Kalevi Nuuja) (05/08/91)
A programmatic approach is sometimes good for keeping the size of files down. A dna model can be represented by a list of A G C and whatever that other letter is, along with a few functions that read that list and create the appropriate primitivies (balls,sticks,letters,etc.) This makes it very easy to alter the way the model is represented (ball+stick,text+stick,space-filling,etc), and its much more compact than explicitly listing each primitive, or even multiply instantiating similiar primitives (need a name, and a location). A progammatic approach allows you to use information from the domain of the model to simplify its encoding. It also makes it easy to create coroegraphy scripts to control rendering animations. You can design whatever function you want to procedurally alter your geometry as time goes by, or load new geometries at appropriate times.
ehg@alice.att.com (Eric Grosse) (05/08/91)
Since there have been several postings this week critical of RenderMan and I have seen no spirited defense from Pixarfolk, I'd like to mention my positive experience with RIB as an interface. In the course of my work in scientific computing, I frequently have occasion to write filters that map numerical simulation data (like finite element solutions) into geometry files to pass off to graphics packages. I suppose these filters qualify as "modelers", though they have little or no interactive component. After exploring a number of alternatives over the years, RIB has come out the winner in my application. The pieces of RenderMan are easy enough to understand, the RIB syntax is easy to parse, and every graphic construct that has been needed for my images was already in the language. In response to particular criticisms: I did get a license from Pixar to write a renderer; it took a couple letters and phone calls, but if you don't have enough energy for that, you probably wouldn't finish the renderer anyway. I've had no trouble writing small driver programs that read the subset of RIB that I happen to be using at the moment and call GL or whatever local graphics library is convenient for quick images. Although my main output is videotape, I'm satisfied with rendering images independently; the surfaces and objects in my images are moving under control of differential equations much too complex for any graphics language to solve. The basic advantage RIB has given me is the ability to make complex images by pasting together the output of several small, independently written tools. I don't need to buy into one of the big visualization programs and figure out how to connect my code to their interface. Eric Grosse AT&T Bell Labs 2T504 Murray Hill NJ 07974 ehg@research.att.com
u87rpb@ecs.oxford.ac.uk (05/08/91)
David Rowley wrote: > I took the postscript interpreter part of GNU's Ghostscript, > and hacked up an interface for Rayshade. I've got a half finished Forth interpreter which I added to the PRT ray tracer that was posted at the end of last year. It's one of the easiest languages to parse (as has been mentioned) whilst at the same time allowing parametric definitions for geometry and texture (and whatever else you might need). To save time parsing, I decided that the Forth code should be converted *once* into a byte stream (a la RenderMan) which could be interpreted very quickly by the renderer itself. The main reason for this was to prevent backtracking through the (ASCII) source whilst rendering, and also to prevent duplicate effort in a parallel environment (there's no point having 50 Sun's all doing a parse job on the same program). When the renderer itself starts, the program is first interpreted to build the object database, and also to insert hooks for procedural texturing. If an object in the database has a hook for texturing, that `word' is then called with the relevant object parameters on the forth stack whenever that object is intercepted. I've not done any work on this since January, but it sounds like a sound idea, so it's definitely something that I'll carry on with next time I have some spare time... Ray.
dwrowley@watserv1.waterloo.edu (David W. Rowley) (05/09/91)
In article <20322@alice.att.com> ehg@alice.att.com (Eric Grosse) writes: > >Since there have been several postings this week critical of RenderMan >and I have seen no spirited defense from Pixarfolk, I'd like to mention >my positive experience with RIB as an interface. In the course of my >work in scientific computing, I frequently have occasion to write filters >that map numerical simulation data (like finite element solutions) into >geometry files to pass off to graphics packages. I suppose these filters >qualify as "modelers", though they have little or no interactive component. >After exploring a number of alternatives over the years, RIB has come out >the winner in my application. The pieces of RenderMan are easy enough to >understand, the RIB syntax is easy to parse, and every graphic construct >that has been needed for my images was already in the language. This sounds exactly like what I was looking for. I am hopeful that RIB will fit the bill. Would you like to donate some RIB parsing code ? David.
unx20238@unx2.ucc.okstate.edu (Lonny) (05/10/91)
Just wondering if anyone out there knows of any X11 graphic editor, cad, or just plain paint programs that will work on an IBM RISC/6000 ? ANY information will be greatly appreciated! Lonny L. Lowe Oklahoma State University Stillwater, Ok 74076 unx20238@unx2.ucc.okstate.edu
aaa@pixar.com (Tony Apodaca) (05/14/91)
There has been a lot of traffic about what RenderMan is and is not in the past couple weeks, so I hope I can clear up some of the confusion. My credentials: currently Chief Architect of the RenderMan Interface, and one of the Unknown Implementors of both of Pixar's image synthesis products. First, I must apologize for the untimeliness of this post. As I type this, it is May 12, and only today has our news feed deigned to send us your postings from April 30! A friend at UCSC has sent me some postings up through May 9 (thanks Rob!), but I have not seen the whole thread. If I cover "old ground", I apologize. This post is likely to be long, because I am (too darn) longwinded. I hope those who are interested will not 'n' this article purely because of it's length. The two documents that describe RenderMan are the Specification (the current version is 3.1, printed December 1989) and the book, "The RenderMan Companion" (written by Steve Upstill). The Specification is the true source, and is available from Pixar (1001 W. Cutting Blvd, Richmond, CA, 94804, (415)236-4000) for $20. We don't make any profit on that, $20 doesn't quite cover printing costs and postage (particularly on foreign requests, of which we get a lot). The book is published by Addison-Wesley, ISBN 0-201-50868-0. The "Companion" is cool because it gives lots of examples and pictures, and is not nearly as technical as the spec. The only problem is that the "Companion" uses C to demonstrate RenderMan, as it was written before the RIB language was codified. I want to correct some factually incorrect statements that have been made about RenderMan. Someone mentioned... > Renderman is grossly inefficient for polygons, as it takes a > [vertex, vertex, close] instead of a list of vertices and a face list. Check out RiPointsPolygons(). I think this will do what you want. Someone claimed that Pixar did not use RenderMan and RIB for its own animations. We most certainly do, and we are quite proud of it. We sell what we use, we use what we sell. People are worried about how hard it is to parse RIB. Believe me, you don't need yacc to parse RIB. It is very simple. To be honest, I am quite surprised there isn't a PD file reader already. I would write one, but I'm not allowed (employment contract and all). Several people were worried about copyrights and licenses and such. Let me put the record straight. Pixar wants RenderMan to be "ubiquitous" (such a nice word!). That means STANDARD. We want other people to write renderers, because if they don't, what good is it to call it a standard? One company does not agreement make. Sure, our marketing department would be really happy if our engineering department produced the best such renderer available, but as a company, we completely recognize the need for honorable competition, and we look forward to it. So what's the deal with licenses? We retain the copyright and require licensing for our own protection, and for the protection of the consumer. Who is helped if someone announces a RenderMan product and they lie? Noone, obviously. We do not restrict or charge fees or make it difficult an any way for someone who tells the truth to get a full license. We've given out many. If anyone out there has had a problem in this regard, please contact me personally, and I will get it straightened out. 'Nuff said. Finally, several people were concerned that RenderMan only "works" for Pixar's Reyes-style renderer. I have heard this on occassion from various places. Sometimes the evidence is "Look, displacements can't be done in a ray tracer, QED". The fact is, RenderMan was designed to be used by any renderer, anywhere. Sure, some features are algorithm-specific, because people who write such renderers asked for them to be there. There are things in RenderMan that can't be done by Reyes that CAN be done by a ray tracer (tranluscent volumes, for example). But these are all "optional". It is a bit much to go into exactly what this means (it's in the spec), but suffice it to say, if the renderer can't do it, it is free to ignore it. If there are any examples of anything in the RenderMan Interface Spec which clearly are impossible in a ray tracer, or in any other mainstream algorithm, I would like to hear about it...and fix it! If it were true, I would have failed, and I don't want to fail. Being "Chief Architect", I am privy to a lot of private plans of various companies using RenderMan, and it would be indiscreet for me to let on what I know, even by innuendo. Let me just say, there is more in store than just bug-fixes for Reyes.... I will now launch into a long explanation of why RenderMan was designed the way it was designed. I think there are some valuable lessons for the person who designed the next modeling and rendering interface. If you are already bored, hit 'n' now. By now, everyone understands the difference between C calls to a RenderMan library and RIB. Yes, RIB is (for all intents and purposes) simply a metafile format for the C library. Why did we choose a C library as the "fundamental" binding, rather that write our own procedural language? Well, because it seemed like the right thing to do at the time. This is not a flippant comment. We (actually Pat Hanrahan, the original father of RenderMan) examined other graphics packages and standards closely. He decided that a procedural interface, in the long tradition of GKS, PHIGS and SGI's GL, was the most flexible and gave the users the most bang per buck. It is simple to write a metafile format for a procedural interface, but it is very awkward to write a procedural interface for a language (ex: Postscript wrappers from a C program). One must remember the domain that RenderMan was set out to cover. We wanted a standardized interface between modeling programs and rendering programs. All sorts of rendering programs, from SGI hardware renderers to Reyes to ray tracers, and everything in between. There were two totally different ways to approach this problem: 1) provide a standard set of really simple primitives that absolutely any renderer could eat, and put the burden on the modeller to convert anything more interesting that *it* knew about into these simple primitives; 2) provide all of the primitives that any modeller could possibly want, and put the burden on the renderer to be so complex that it could handle anything. Any new rendering interface has to face this question, and believe me, it is the hardest one of all. We tried to compromise, to fill as many people's needs as we could without getting PL/1 (anyone remember PL/1?). We provided a "very rich" set of primitives, anything that renderers might reasonably be expected to be able to "take advantage of", but do not solve every modelling problem. For example, we take spheres directly, because ray tracers can certainly trace spheres a lot faster than some collection of 2000 triangles. Similarly, we take CSG and object hierarchies directly. On the other hand, we don't take surfaces of revolution directly. These are easily described with the other primitives, and offer renderers no real advantage. So, we made our decision. What kind of flack do we get for it? You might be able to guess: people who are writing renderers say, "This interface is too darn complex. Noone could ever meet it." People who are writing modellers say, "My modeller has the one neato concept that really ought to be in the interface, can't you see your way clear to add it?" But what about animation? Doesn't that require a procedural interface? We struggled with two important constraints which many people don't think about: 1) the animation that the average Joe on the street does is simple now, but is going to get more and more complex as computers and renderers get faster and faster; 2) any procedural language which we were to define has to be better than C. What do we mean by simple animation? We all know the type... flying logos, camera moves over static scenes, robot arms and spaceships. Basically, simple rigid motions over repetitive objects. Our own animation has shown us that people are bored of this, and want to move to complex animation: soft, squishy surfaces which deform as they move, faces and bodies, scenes with zillions of objects. Everyone wants to see and do this type of animation, but what does it do to the image description? Well, for one thing, almost NOTHING is constant from one frame to the next. Oh, the occasional desk or wall, but the size of the data in the description of the wall is microscopic in comparison to size of the data in the description of the baby's crying face. It makes a lot of sense to optimize for the big, changing data, rather than the small, static data. And everyone who does these kinds of animations has their own special tricks for managing the huge amount of data this kind of animation requires. Some things might be simple, like a particle system or an evolving fractal, but for some people it is gargantuan systems of differential equations, hydrodynamic equations of the third order, or even giant databases of the complete motion of every one of the individual control points (vertices) in the scene. Could we design a language which could encompass all this, and do it better than Lisp or C? Hardly. General purpose languages are just too powerful (imagine that!). Special purpose languages only help if the domain is very small (Postscript), or if they are pure amplifications of a general purpose language (Shading Language). C/Lisp/Ada are just too good. (Okay, maybe not Ada. ;-) ) So, what have we learned? Modeling languages are hard. Very hard. This is not to say impossible, and I look forward to the day when a smart person solves this problem. But Pixar didn't (and doesn't) know the answer. Pixar has at least 3 modeling and animation languages we use, each of which handles some things very well and other things very poorly. The original poster said he was looking for a "new, text-based, standard modelling format", and then went on to describe some features of a rendering format not too different from RenderMan (some primitives, shading parameters, etc.). Other posters have described their needs for a much more general animation language. I encourage people to keep these two concepts separated. The data necessary for describing (good, complex) modeling and animation is very different from the data necessary to do a photorealistic rendering of a single frame from this animation. And beware the temptation to "add programming constructs" to a line-oriented database format. It will end up ugly and not very useful. If you want a good language, you must design it as a language from the start. If you have made it this far, you are brave indeed. If anyone has specific questions or comments about RenderMan, I'd be happy to answer them. -- UUCP: {sun,ucbvax}!pixar!aaa Tony Apodaca Internet: aaa@pixar.com Pixar, Richmond, CA, USA "And in the end, the love you take is equal to the love you make."
mccoy@pixar.com (Dan McCoy) (05/14/91)
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. Sorry to hear that. I believe some of your complaints are based on a misunderstanding of the RenderMan Interface. I'll try to clarify. > Perhaps 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. > > 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 take this to mean that you dislike the lack of animation control information in the RenderMan Interface. This is, arguably, a weakness of the current RenderMan standard. So yes, as it stands RenderMan is a "scene description language" and not an "animation description language". Control information could possibly make its way into the standard in the future. Currently, the time it takes to render a high quality image dwarfs the time involved in reading a new file for each frame. That is even more true of ray tracers and beyond than it is with the "other scan line rendering program" that we currently sell. > 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. Did you look at the RiPointsPolygons call? It sounds like what you want. Besides, if you want efficifient descriptions of objects, then patches, patch meshes, quadrics, and NURBS are all superior to polygons. Also much information required by a high quality renderer is lost if curved surfaces are expressed as polygons. > Finally the concept of an actor/object is non-existant >in RenderMan. There is no grouping of faces with different >properties or relationships defined. Current implementations of RenderMan renderers may not have the features you want. But the RenderMan Interface provides flexible support for this sort of extension with the RiAttribute call along with RiAttributeBegin/End blocks. The set of attributes that can be specified is not closed. As implementations of RenderMan compatible programs arise, they are free to add implementation specific attributes. > 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!] This is a chicken-egg sort of problem. The interface hasn't been around that long. So far the only reason that people have modified their modellers to output RenderMan compatible files (RIB files) is to allow them to be renderered by Pixar's renderer. Now that many modellers can output their geometry in RIB format, I'm sure you'll start seeing programs that read RIB files as well as write them. > PLEASE SOMEONE! Work on a scene description file format >that will describe an animation or scene, not just the >resultant list of polygons. The RenderMan Interface provides much more than a "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...). RiBound provides bounding boxes. The only thing you ask for that isn't covered by the current RenderMan Interface is motion (beyond motion blur within a frame). It could be argued that this is outside the scope of a "scene description" standard. An example of how to provide what you want without starting from scratch: Motion control could be provided as a separate control file. This control file along with a properly formatted RIB file could either be read by filter program which combines them and outputs to a current level RenderMan renderer. Or the files could be read by a new smarter renderer that could make use of the control information. This has the advantage of being able to compactly express more than one animation sequence for a given geometry file. Dan McCoy Pixar
bcorrie@csr (Brian Corrie) (05/14/91)
aaa@pixar.com (Tony Apodaca) writes: > There has been a lot of traffic about what RenderMan is and is not >in the past couple weeks, so I hope I can clear up some of the confusion. >My credentials: currently Chief Architect of the RenderMan Interface, and >one of the Unknown Implementors of both of Pixar's image synthesis products. > First, I must apologize for the untimeliness of this post. As I >type this, it is May 12, and only today has our news feed deigned to send us >your postings from April 30! A friend at UCSC has sent me some postings >up through May 9 (thanks Rob!), but I have not seen the whole thread. I was wondering why no one from Pixar was speaking up. Now we know. Today, I got three postings from Pixar defending RenderMan 8-) Nice to hear from you guys... [Stuff deleted about ordering the RenderMan spec. etc] > I want to correct some factually incorrect statements that have >been made about RenderMan. Someone mentioned... >> Renderman is grossly inefficient for polygons, as it takes a >> [vertex, vertex, close] instead of a list of vertices and a face list. >Check out RiPointsPolygons(). I think this will do what you want. This misunderstanding was caused for a couple of reasons I think. 1) John Woolverton (as he explains in his recent posting) based his info on the output of modelers that he used, none of which used this feature. 2) RIB is purely a textual format, correct? That is there are no variables or static arrays that can be declared. Therfore, if you have a large number of polygons to be declared with a large set of common vertices, then you either declare separate polygons with duplicate vertex info, or use one large RiPointsPolygons declaration for all polygons. For exmaple, to be really efficient (as in the OFF file format) you would declare a list of all vertices in an object, and then the entire list of polygons that makes up the entire object. This isn't terribly obvious that its the way to go, especially when you are thinking of the C binding and then convert that to RIB. This makes for a single RiPointsPolygon call that could have thousands of polygons in it, not the most obvious way to go (but the most efficient) when you think about it. > Someone claimed that Pixar did not use RenderMan and RIB for its own >animations. We most certainly do, and we are quite proud of it. >We sell what we use, we use what we sell. I hope this wasn't my statement that gave you this impression. If so, what I meant to say was that I thought Pixar uses other tools/langauges as well/on top of RenderMan. You confirm this later in your article when you say... > So, what have we learned? Modeling languages are hard. Very hard. >This is not to say impossible, and I look forward to the day when a smart >person solves this problem. But Pixar didn't (and doesn't) know the answer. >Pixar has at least 3 modeling and animation languages we use, each of which >handles some things very well and other things very poorly. [More explanation/description deleted] > Being "Chief Architect", I am privy to a lot of private plans of >various companies using RenderMan, and it would be indiscreet for me to let >on what I know, even by innuendo. Let me just say, there is more in store >than just bug-fixes for Reyes.... Sounds interesting, I'll keep my eyes and ears open 8-) [Interesting exlpanation of the design decisions wrt RenderMan deleted] >-- >UUCP: {sun,ucbvax}!pixar!aaa Tony Apodaca >Internet: aaa@pixar.com Pixar, Richmond, CA, USA > "And in the end, the love you take is equal to the love you make." Later, 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-)
richard@mee.tcd.ie (05/14/91)
If this scene description language gets off the ground in a big way, it means that watching T.V. in the future will be a lot more interesting. Say for example in ten years time you're sitting watching T.V. one day (say Casablanca for example), and suddenly the reception becomes bad and Bogie's trenchcoat turns into a polkadot leotard, his cigar a cucumber, and his tremondously stylish hat becomes a mahogany coloured tin of smoked salmon. Personally, I can't wait. Richard Bolger // Trinity College Dublin // rbolger@vax1.tcd.ie Republic of Ireland //