aaa@pixar.com (Tony Apodaca) (03/19/91)
In article <bcorrie.668714394@csr> bcorrie@csr (Brian Corrie) writes: >parnoux@dorsai.com (patrick arnoux) writes: > >>CAVSoftware in New York City has a renderer running on the Pixel Machine >>which reads RIB files (RenderMan Interface Bytestream). The implementation >>is fairly complete (Just read Steve Upstill's book, all the information >>is there). But while it is possible to generate images from Dimension, >>Macromind, Strata, Swivel, and most other modelers that output RIB, the >>program cannot deal with "shader files". Pixar does not release the >>format of the .slo files, therefore only a limited number of preset >>shader types are built into the program.... > >Can anyone fill me in on just what a .slo file is? I am playing/thinking >about RenderMan and the shading language, but do not have access to any >RenderMan renderers, so don't know how they work. Is the shading language >interpreted at run/render time, or do they do dynamic loading of the >shader descriptions some how, with the .slo files the executables for >the shader?? I might be able to clear up some confusion here.... A geometric model described with the RenderMan Interface comes in two parts: the "shape" description (the RIB file) and the "shade" description (the shader files). Steve's book describes both the C interface to the shape library, as well as the RenderMan Shading Language (a C-like language). Shading Language programs typically have a ".sl" file extention. The RenderMan Interface Specification describes both parts in even more gory detail. They are both publicly available formats. It turns out that the renderer Pixar sells (PhotoRealistic-RenderMan) has a run-time interpreter of sorts which processes the shading language. It can't read the source code directly, instead it reads a "predigested" version which is typically stored in a ".slo" file. The .slo file is some bizarre private format used by that interpreter. However, that is not important. A different renderer might read the source code directly, or might compile it into a "real .o" file and dynamically link it. Whatever works. If some renderer cannot accept shader files, it is because writing a renderer which supports user-programmable shading is REALLY HARD, not because .slo files are somehow magical or secret. The magic is in the renderer! I am glad to hear that there is a RenderMan-compatible renderer available for the AT&T Pixel Machine (I had not heard of it before). Does anyone out there have any experience with it they could share? P.S. Steve will be glad to know you liked his book! ;-) -- UUCP: {sun,ucbvax}!pixar!aaa Tony Apodaca ARPA: aaa@pixar.com Chief Architect US Snail: 1001 W Cutting, Richmond, CA 94804 RenderMan Interface
po0o+@andrew.cmu.edu (Paul Andrew Olbrich) (03/19/91)
Tony Apodaca writes: > If some renderer cannot accept shader files, it is because writing > a renderer which supports user-programmable shading is REALLY HARD, > not because .slo files are somehow magical or secret. The magic is in > the renderer! An easy way to do this is to have your renderer be a big archive or library, and then describe a scene to be rendered using a language such as C. (With a RenderMan-ish syntax.) The scene description is then compiled and linked to the rendering library, forming a big executable which generates your image. You do get the linking overhead, and wind up with a large executable, but this far outweighs the flexibility you get from describing your scenes in C. It is also trivial to write shading routines (again in C) that are called by the rendering library. In comparison to the way most of the existing PD renderers work, this method gives you the extreme flexibility of using a language for scene and shading descriptions, by using an existing parser (the C language.) You avoid the icky business about writing a compiler/loader for the shading routines that the user writes, too. Does this make sense? ... (I'm a little incoherant at the moment after pulling an all-nighter... my apologies.) Drew Olbrich po0o@andrew.cmu.edu PS. If anyone is interested I can answer questions about how to implement something like this. I wrote a ray tracer that works this way with CSG, object heirarchies, K/K bounding slabs, and shading language support. Oh another benefit is when I do animation with this, I can generate a single executable that generates all the frames based on a time parameter. Since scene descriptions are all C, I can throw in splines or make up silly functions to control movement. I did a short physical simulation, and wrote that right into the scene description. To generate the scene for a given frame, it would simulate the dynamics up till that frame. This saves a lot of disk space. This probably should be done in C++, I think, to be truely nifty.
jonas-y@isy.liu.se (Jonas Yngvesson) (03/19/91)
po0o+@andrew.cmu.edu (Paul Andrew Olbrich) writes: >An easy way to do this is to have your renderer be a big archive or >library, and then describe a scene to be rendered using a language such as C. >(With a RenderMan-ish syntax.) The scene description is then compiled and >linked to the rendering library, forming a big executable which generates >your image. ... >Does this make sense? ... (I'm a little incoherant at the moment after pulling >an all-nighter... my apologies.) Sure does. >PS. If anyone is interested I can answer questions about how to implement >something like this. I wrote a ray tracer that works this way with CSG, >object heirarchies, K/K bounding slabs, and shading language support. >Oh another benefit is when I do animation with this, I can generate >a single executable that generates all the frames based on a time >parameter. Since scene descriptions are all C, I can throw in splines or >make up silly functions to control movement. I did a short physical >simulation, and wrote that right into the scene description. To generate >the scene for a given frame, it would simulate the dynamics up till >that frame. This saves a lot of disk space. >This probably should be done in C++, I think, to be truely nifty. You can also pick up the SIPP rendering library from some ftp site. It is a library for rendering objects built of polygons using a scan line z-buffer and Phong shading. It uses just this approach. Each surface has a pointer to the shading function it should be shaded with. It is for example availiable from isy.liu.se (130.236.1.3) as pub/sipp-2.0.tar.Z --Jonas -- ------------------------------------------------------------------------------ J o n a s Y n g v e s s o n Dept. of Electrical Engineering jonas-y@isy.liu.se University of Linkoping, Sweden ...!uunet!isy.liu.se!jonas-y
uad1077@dircon.co.uk (Ian Kemmish) (03/24/91)
po0o+@andrew.cmu.edu (Paul Andrew Olbrich) writes: >An easy way to do this is to have your renderer be a big archive or >library, and then describe a scene to be rendered using a language such as C. >(With a RenderMan-ish syntax.) The scene description is then compiled and >linked to the rendering library, forming a big executable which generates >your image. >You do get the linking overhead, and wind up with a large executable, but this >far outweighs the flexibility you get from describing your scenes in C. >It is also >trivial to write shading routines (again in C) that are called by the rendering >library. >In comparison to the way most of the existing PD renderers work, this method >gives you the extreme flexibility of using a language for scene and shading >descriptions, by using an existing parser (the C language.) You avoid the >icky business about writing a compiler/loader for the shading routines that the >user writes, too. >Does this make sense? ... (I'm a little incoherant at the moment after pulling >an all-nighter... my apologies.) >Drew Olbrich >po0o@andrew.cmu.edu An alternative which maintains portability of the scene description (without recompiling:-]) is to use an interpreted language for the shaders, mingled in the same stream as the geometry information (though suitably delimited, of course!). I'm no expert at writing interpreters, but even in my humble effort, most of the optimisations that Pixar's paper at last year's SIGGRAPH mention come out in the wash. Someone who knew what he was doing could probably make the interpreter overhad disappear altogether:-). -- Ian D. Kemmish Tel. +44 767 601 361 18 Durham Close uad1077@dircon.UUCP Biggleswade ukc!dircon!uad1077 Beds SG18 8HZ United Kingdom uad1077@dircon.co.uk
parnoux@dorsai.com (patrick arnoux) (03/30/91)
aaa@pixar.com (Tony Apodaca) writes: > > have a ".sl" file extention. The RenderMan Interface Specification > describes both parts in even more gory detail. They are both publicly > available formats. > It turns out that the renderer Pixar sells (PhotoRealistic-RenderMan) > has a run-time interpreter of sorts which processes the shading language. > It can't read the source code directly, instead it reads a "predigested" > version which is typically stored in a ".slo" file. The .slo file is > some bizarre private format used by that interpreter. However, that is > not important. A different renderer might read the source code directly, > or might compile it into a "real .o" file and dynamically link it. > Whatever works. > If some renderer cannot accept shader files, it is because writing > a renderer which supports user-programmable shading is REALLY HARD, > not because .slo files are somehow magical or secret. The magic is in > the renderer! > In order to be compatible with PhotoRealistic-RenderMan (c)Pixar it is necessary to implement a renderer which also understand ".slo" files. In a production environement, where you have a couple or a dozen Macs and/or PC clones feeding RIB/shader files to the Pixel Machine (via the Sun or whatever host being used) rolling your own is not an option, unless the modeling packages being used on the Macs/PCs were modified. The idea is to have a Standard environement across all the platforms, so that I can use all the modelers out there that generate RIB files and use the shaders that they are using and use all the shaders that have not been provided in source form. In short I believe in taking the long term view and global approach. Before any images can be generated, they have to be modelled and the complete picture requires that the entire process be taken into account, from generating the objects to the final image. Therefore I disagree that the magic is in the renderer as you put it. Even though the RIB and shading language formats are described in excedingly "gory details" the format of the shader compiler which outputs that "predigested" ".slo" file is not. And that same ".slo" file is the one used by the modellers and which is sometimes not provided in source format. If one were to work in a stand-alone environement then the outside world would not matter and "Whatever works" would be fine. But in order to function in the real world, one has to interface to the real world, and rolling your own does not always work. parnoux (patrick arnoux)
bcorrie@csr (Brian Corrie) (04/03/91)
parnoux@dorsai.com (patrick arnoux) writes: >aaa@pixar.com (Tony Apodaca) writes: >> >> have a ".sl" file extention. The RenderMan Interface Specification >> describes both parts in even more gory detail. They are both publicly >> available formats. >> It turns out that the renderer Pixar sells (PhotoRealistic-RenderMan) >> has a run-time interpreter of sorts which processes the shading language. >> It can't read the source code directly, instead it reads a "predigested" >> version which is typically stored in a ".slo" file. The .slo file is >> some bizarre private format used by that interpreter. However, that is >> not important. A different renderer might read the source code directly, >> or might compile it into a "real .o" file and dynamically link it. >> Whatever works. >> If some renderer cannot accept shader files, it is because writing >> a renderer which supports user-programmable shading is REALLY HARD, >> not because .slo files are somehow magical or secret. The magic is in >> the renderer! >> >In order to be compatible with PhotoRealistic-RenderMan (c)Pixar (My two cents - Warning, I have never even seen PhotoRealistic-RenderMan, but I do have some thoughts on this topic) If I understand things correctly, PhotoRealistic-Renderan is an implementation of the RenderMan Standard (by Pixar). One does not want to be compatible with it, but the RenderMan Interface itself. >it is necessary to implement a renderer which also understand ".slo" >files. In a production environement, where you have a couple or a dozen >Macs and/or PC clones feeding RIB/shader files to the Pixel Machine >(via the Sun or whatever host being used) rolling your own is not >an option, unless the modeling packages being used on the Macs/PCs >were modified. The idea is to have a Standard environement across >all the platforms, so that I can use all the modelers out there >that generate RIB files and use the shaders that they are using >and use all the shaders that have not been provided in source form. >In short I believe in taking the long term view and global approach. >Before any images can be generated, they have to be modelled and >the complete picture requires that the entire process be taken >into account, from generating the objects to the final image. > Therefore I disagree that the magic is in the renderer as you >put it. Even though the RIB and shading language formats are described >in excedingly "gory details" the format of the shader compiler which >outputs that "predigested" ".slo" file is not. And that same ".slo" >file is the one used by the modellers and which is sometimes not >provided in source format. .slo files are not part of the standard, and it sounds like (as Tony says), they are just compiled versions of the shader descriptions (which are part of the interface). It is the shader descriptions that are part of the standard. I don't feel that they have any obligation to share their secrets in the .slo files, as they represent research that give them an advantage over other vendors. The fact that the ideas behind most of the secrets are published (See Hanrahan & Lawson, Computer Graphics, Volume 24, Number 4, August 1990) make it a matter of a vendor implementing those ideas. The fact that Pixar has done the pioneering work in this area gives them a ``small'' advantage in the sense that they have had access to this stuff for years, and therfore their technology is more advanced. It seems the only magic in the .slo files is how they perform the optimizations to make the interpretation of the shader description fast and efficient. On the other hand, I think it is important that the shader descriptions are avaialable for everyone to see and use. The shader descriptions are the components that should be used by the modeller and the renderers. I would assume that one can create a shader in the modeller, save it as a shader, compile it to get a .slo file, and then use the renderer. This implies that Pixar provides both the PhotoRealistic-RenderMan renderer and the shader compiler together. Is this true????? If you can not save the shader description as specified by the standard, then I would agree that this is a serious limitation, as that shader can not be used on other architectures or by other renderers. That kinda defeats the purpose of having a standard, now doesn't it! Again, because I don't actually use these beasties, I need enlightenment in that regard. > If one were to work in a stand-alone environement then the >outside world would not matter and "Whatever works" would be fine. >But in order to function in the real world, one has to interface >to the real world, and rolling your own does not always work. > parnoux (patrick arnoux) Thats all for now..... 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-)