zap@lysator.liu.se (Zap Andersson) (05/09/91)
I think that a scene description language, empasizing the word SCENE, as RenderMan does is problematic (not saying it's a Bad Thing). What I propose is a Model description language, describing: * Geometries * Lights * Semi-surfaces * Named transformations that can later be changed ? (The latter for the animation folks... :-) Note the 'semi' on surfaces, that is a big hitch in renderers. Of course we should pass the geometries as good as possible. But surfaces ARE a problem. In my mind, the Pixar approach with user-programmable shading, is a) Too complex to implement (yes I'm lazy) b) Too complex to the average luser Also, if the shading is part of the interface, it is bound to lay some constrains on what can and what cannot be done, thus limiting creativity. As I see it, the difference between most PD tracers is not what geometries they eat (even if they eat NFF, OFF, DXF, RTK, XYZ, HIC, ETC) but how they shade them. Some use 3d textures, some use 2d bitmapps, some use wavesources and other use other things. Some use projective mapping, some use parameters on the surfaces for mapping, and some has texturemap coordinates stored in each vertex... This is a problem to standardize, and is why I cant support renderman in my renderer. Where do I put the texturemap coordinates 'per vertex' in a sphere :-) Also, to MY warped mind, all these differences are the strengths and weaknesses of the renderers! If we standardize these, why write more than one renderer in the first place (and take all the fun out of it) :-( ? I'm not saying standards is a Bad Thing. I'm not saying Renderman is a Bad Thing. I'm just saying that they might somehow kick creativity, an d they may take an awful lot of time, if they are too complex. Like I said in an earlier post: Let's define RayMond interface as: * Renderman primitives * All features of renderman with things impossible in raytracing (e.g. true displacement shading) ripped out * Effichiency shemes thrown in * Editable objects (move, squach, fiddle) * Not nessecarily having standardized shading When a raymond surface wants to be wood, it should say so, and spit out the settings for 'wood' as it was defined in the renderer/modeller creating that file. However, if the other renderer is different, it only cares about those parts of the shading it can understand, such as ambient light, surface color e.t.c. and tells the user: Hey user, this is supposed to be wood, want to alster something to make it look more like that? And the user can. Sorry for being incmprhnsibl, I'm under timestrain (bus in 1 minute ;-) and a stupid keyboard. CU all! -- * * * * * * * * * * * * * * * * * (This rent for space) * My signature is smaller than * Be warned! The letter 'Z' is Copyright 1991 * yours! - zap@lysator.liu.se * by Zap Inc. So are the colors Red, Green and * * * * * * * * * * * * * * * * * Greenish-yellow (Blue was taken by IBM) -- * * * * * * * * * * * * * * * * * (This rent for space) * My signature is smaller than * Be warned! The letter 'Z' is Copyright 1991 * yours! - zap@lysator.liu.se * by Zap Inc. So are the colors Red, Green and * * * * * * * * * * * * * * * * * Greenish-yellow (Blue was taken by IBM)
bcorrie@csr (Brian Corrie) (05/11/91)
zap@lysator.liu.se (Zap Andersson) writes: >I think that a scene description language, empasizing the word SCENE, as >RenderMan does is problematic (not saying it's a Bad Thing). What I >propose is a Model description language, describing: >* Geometries >* Lights >* Semi-surfaces >* Named transformations that can later be changed ? >(The latter for the animation folks... :-) >Note the 'semi' on surfaces, that is a big hitch in renderers. Of course >we should pass the geometries as good as possible. But surfaces ARE a >problem. In my mind, the Pixar approach with user-programmable shading, is > >a) Too complex to implement (yes I'm lazy) >b) Too complex to the average luser >Also, if the shading is part of the interface, it is bound to lay some >constrains on what can and what cannot be done, thus limiting creativity. I don't follow. The idea of the RenderMan shading language was to allow the flexibility of the user to do what he/she/it wanted to do. What do you propose that would allow more flexibility? Some how you have to describe to the renderer what you want it to do. A shading language is by far the most powerful way of doing this (at least that I know of). See below for avoiding it for the programmer and the user. > >As I see it, the difference between most PD tracers is not what geometries >they eat (even if they eat NFF, OFF, DXF, RTK, XYZ, HIC, ETC) but how they >shade them. Some use 3d textures, some use 2d bitmapps, some use wavesources >and other use other things. Some use projective mapping, some use parameters >on the surfaces for mapping, and some has texturemap coordinates stored in >each vertex... > >This is a problem to standardize, and is why I cant support renderman in >my renderer. Where do I put the texturemap coordinates 'per vertex' in >a sphere :-) I think that the shading langauge can describe all of these techniques (by some contortion or another). Anyone out there at the RenderMan Course at last years SIGGRAPH in Dallas. I seem to remember one of the lecturers (Darwyn Peachey maybe???) mentioning that to get one of the special effects they wanted, they actually wrote a sub-ray tracer in the shading language that somehow created its own objects and ray traced them or something. Amazing, but I would never want to try it 8-) >Also, to MY warped mind, all these differences are the strengths and >weaknesses of the renderers! If we standardize these, why write more than >one renderer in the first place (and take all the fun out of it) :-( ? > >I'm not saying standards is a Bad Thing. I'm not saying Renderman is a >Bad Thing. I'm just saying that they might somehow kick creativity, an >d they may take an awful lot of time, if they are too complex. I think it extends creativity if the shading langauge is implemented. Sure it is hard to implement, and most people out there won't take the time to use/create whiz bang shaders. Too have the potential ability to do it in some renderers will be worth it. >Like I said in an earlier post: Let's define RayMond interface as: >* Renderman primitives >* All features of renderman with things impossible in raytracing > (e.g. true displacement shading) ripped out >* Effichiency shemes thrown in >* Editable objects (move, squach, fiddle) >* Not nessecarily having standardized shading > >When a raymond surface wants to be wood, it should say so, and spit out >the settings for 'wood' as it was defined in the renderer/modeller >creating that file. However, if the other renderer is different, it >only cares about those parts of the shading it can understand, such as >ambient light, surface color e.t.c. and tells the user: Hey user, >this is supposed to be wood, want to alster something to make it look >more like that? >And the user can. > >Sorry for being incmprhnsibl, I'm under timestrain (bus in 1 minute ;-) >and a stupid keyboard. Hope you made your bus 8-) My point is this language can be really powerful if you want it to be. Another important point is that it doesn't have to be. In the RIB description, to instantiate a shader one does something like: Surface "wood" "ringcolor" [.8 .8 0] Now if my renderer reads RIB, but can't handle wood, it just sees the surface description for wood and says ``opps, sorry user, I can't render wood'' and ignores this description. Your renderer wouldn't have to care about the shading language at all if it didn't want to. It could just use the primitives. An easy extension - if you see the shader above being instanced, and you know how to do wood, just do wood, and ignore the shader description itself! What a RenderMan compliant renderer would do is find the shader WOOD, bind it to the primitive, and set up to interpret the shader description for the wood shader. You don't have to though. To be RenderMan compliant you must provide the standard shaders, but they are the easy ones (constant, matte, plastic, metal etc...). Most renderers can already do this. Only the advanced ones will be able to interpret a shader description. So to go through your list: >Like I said in an earlier post: Let's define RayMond interface as: >* Renderman primitives RenderMan has these 8-) >* All features of renderman with things impossible in raytracing > (e.g. true displacement shading) ripped out Ignore them in your implementation. The displacement stuff is part of the shading language, so if you ignore the shading language, you ignore the displacement mapping. >* Effichiency shemes thrown in This is part of the renderer. Some help in the interface may be a bonus, but I don't know that it should be part of the standard. In a sense, the graphics state can be used to realize a hierarchical structure in the objects. Since things within a transformation block are likely related (since they are transformed together) this can be used to get a tree structure on the objects for those techniques that use such an algorithm. As a fundamental question, I don't think that the modeler/renderer interface should specify how things are grouped. It should be a job of the renderer to determine this hierarchy based on the efficiency scheme that it uses. If it can't determine a good hierarchy for an arbitrary scene, then it is probably not a terribly good efficiency scheme (Now that I've said that, lets temper the remark with the fact that this is an open research question in ray tracing. I don't think any efficeincy scheme works best on all scene descriptions. The good ones do well most of the time though 8-) >* Editable objects (move, squach, fiddle) Yeah, RenderMan is lacking in the transformation/deformation arena, but I think that is a whole new ball game. Maybe we need another layer on top of RenderMan that does these more complex operations for animation, and spits out RIB code for each frame. >* Not nessecarily having standardized shading Don't want it, ignore them! Or do your best with them. Or implement them. Whatever! >CU all! I just don't think we should start from scratch again, when all this work has been done by Pixar to get a pretty good semi-standard out there already. I just hope some kind soul out there will post a yacc grammar for RIB some day to make it easy on everyone who wants to parse it. It should be pretty simple to make the grammar, just tedious, cause there are lots of RIB functions to parse, so there will be lots of rules.... >-- >* * * * * * * * * * * * * * * * * (This rent for space) >* My signature is smaller than * Be warned! The letter 'Z' is Copyright 1991 >* yours! - zap@lysator.liu.se * by Zap Inc. So are the colors Red, Green and >* * * * * * * * * * * * * * * * * Greenish-yellow (Blue was taken by IBM) >-- >* * * * * * * * * * * * * * * * * (This rent for space) >* My signature is smaller than * Be warned! The letter 'Z' is Copyright 1991 >* yours! - zap@lysator.liu.se * by Zap Inc. So are the colors Red, Green and >* * * * * * * * * * * * * * * * * Greenish-yellow (Blue was taken by IBM) It was smaller when there was only one signature 8-) 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-)
zap@lysator.liu.se (Zap Andersson) (05/13/91)
[Lot 'o blah blah of min deleted] >I think it extends creativity if the shading langauge is implemented. Sure >it is hard to implement, and most people out there won't take the time to >use/create whiz bang shaders. Too have the potential ability to do it in some >renderers will be worth it. >> >>Sorry for being incmprhnsibl, I'm under timestrain (bus in 1 minute ;-) >>and a stupid keyboard. >Hope you made your bus 8-) I did. And it was only th databus. I will need to take the adress bus today... >My point is this language can be really powerful if you want it to be. Another >important point is that it doesn't have to be. In the RIB description, to >instantiate a shader one does something like: >Surface "wood" "ringcolor" [.8 .8 0] >Now if my renderer reads RIB, but can't handle wood, it just sees the surface >description for wood and says ``opps, sorry user, I can't render wood'' and >ignores this description. Your renderer wouldn't have to care about the shading >language at all if it didn't want to. It could just use the primitives. Yeah, stupid of me, this works xactly th way I want it (DAMN KYBOARD MY 'E' is stupid) >An easy extension - if you see the shader above being instanced, and you know >how to do wood, just do wood, and ignore the shader description itself! What a >RenderMan compliant renderer would do is find the shader WOOD, bind it to the >primitive, and set up to interpret the shader description for the wood shader. >You don't have to though. To be RenderMan compliant you must provide the standard Yeah, rite. You are sooo right. >So to go through your list: >>Like I said in an earlier post: Let's define RayMond interface as: >>* Renderman primitives >RenderMan has these 8-) :-) >>* All features of renderman with things impossible in raytracing >> (e.g. true displacement shading) ripped out >Ignore them in your implementation. The displacement stuff is part of the >shading language, so if you ignore the shading language, you ignore the >displacement mapping. Yes, corrct, displacmnt shading is 'optional' >>* Effichiency shemes thrown in >This is part of the renderer. Some help in the interface may be a bonus, but >I don't know that it should be part of the standard. In a sense, the graphics >state can be used to realize a hierarchical structure in the objects. Since >things within a transformation block are likely related (since they are >transformed together) this can be used to get a tree structure on the objects >for those techniques that use such an algorithm. As a fundamental question, >I don't think that the modeler/renderer interface should specify how things >are grouped. It should be a job of the renderer to determine this hierarchy >based on the efficiency scheme that it uses. If it can't determine a good >hierarchy for an arbitrary scene, then it is probably not a terribly good >efficiency scheme (Now that I've said that, lets temper the remark with the >fact that this is an open research question in ray tracing. I don't think >any efficeincy scheme works best on all scene descriptions. The good ones >do well most of the time though 8-) AHA! NOW you ar on deeeep watrs my friend, a topic near and dear to my heart :-) hh heh heh :-) Like you said: No scheme is best for all images. Oftn, th bst way is to allow th modllr (i.e. the luser) to say: OK, this thing I want a grid around, do octr around these, and do bounding boxes hre, and zap-locked thermal tracing on those balls in the corner... >>* Editable objects (move, squach, fiddle) >Yeah, RenderMan is lacking in the transformation/deformation arena, but I >think that is a whole new ball game. Maybe we need another layer on top of >RenderMan that does these more complex operations for animation, and spits >out RIB code for each frame. Right again >>* Not nessecarily having standardized shading >Don't want it, ignore them! Or do your best with them. Or implement them. >Whatever! RIGHT AGAIN! >>CU all! >I just don't think we should start from scratch again, when all this work >has been done by Pixar to get a pretty good semi-standard out there already. >I just hope some kind soul out there will post a yacc grammar for RIB some >day to make it easy on everyone who wants to parse it. It should be pretty >simple to make the grammar, just tedious, cause there are lots of RIB >functions to parse, so there will be lots of rules.... Yah, this is in som sns what I wantd to say in my post, but due to bus stress and mor it ended up quite strang: What I wantd to say is: * Do rndrman as far as possibl * Don't nessasarily to rndrman shading (dont work too long on somhing that isn't ndd) DAMN KYBOARD! * Throw in schmes (Still think this - th only point you didn't convinc me! :-) >>* * * * * * * * * * * * * * * * * (This rent for space) >>* My signature is smaller than * Be warned! The letter 'Z' is Copyright 1991 >>* yours! - zap@lysator.liu.se * by Zap Inc. So are the colors Red, Green and >>* * * * * * * * * * * * * * * * * Greenish-yellow (Blue was taken by IBM) >It was smaller when there was only one signature 8-) Yeah, and it was smallr if th news softwar didn't includ it twiz... sigh >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-) -- * * * * * * * * * * * * * * * * * (This rent for space) * My signature is smaller than * Be warned! The letter 'Z' is Copyright 1991 * yours! - zap@lysator.liu.se * by Zap Inc. So are the colors Red, Green and * * * * * * * * * * * * * * * * * Greenish-yellow (Blue was taken by IBM)
bcorrie@csr (Brian Corrie) (05/14/91)
zap@lysator.liu.se (Zap Andersson) writes: >[Lot 'o blah blah of min deleted] [Lots of mine deleted too] [You say] >>>* Effichiency shemes thrown in [I say] >>This is part of the renderer. Some help in the interface may be a bonus, but >>I don't know that it should be part of the standard. In a sense, the graphics >>state can be used to realize a hierarchical structure in the objects. Since >>things within a transformation block are likely related (since they are >>transformed together) this can be used to get a tree structure on the objects >>for those techniques that use such an algorithm. As a fundamental question, >>I don't think that the modeler/renderer interface should specify how things >>are grouped. It should be a job of the renderer to determine this hierarchy >>based on the efficiency scheme that it uses. If it can't determine a good >>hierarchy for an arbitrary scene, then it is probably not a terribly good >>efficiency scheme (Now that I've said that, lets temper the remark with the >>fact that this is an open research question in ray tracing. I don't think >>any efficeincy scheme works best on all scene descriptions. The good ones >>do well most of the time though 8-) [Oh Oh, I'm in trouble 8-)] >AHA! NOW you ar on deeeep watrs my friend, a topic near and dear to >my heart :-) hh heh heh :-) >Like you said: No scheme is best for all images. Oftn, th bst way is to >allow th modllr (i.e. the luser) to say: OK, this thing I want a grid >around, do octr around these, and do bounding boxes hre, and zap-locked >thermal tracing on those balls in the corner... I agree that it is often necessary to do this, but the number of different ways that renderers can provide efficiency techniques seems like too complex of a requirement to put on a modeller/renderer interface. RenderMan does provide hierarchy to a degree (Ri*Begin/Ri*End blocks) as well as bounding boxes, two of the most common efficiency schemes. Unfortuantely, different rendering schemes use very different techniques to acclerate things (Scan line techniques VS Ray Tracing for example). I think maybe the best way to deal with this is to extend the RIB interface to suit your renderer a bit. I don't know for sure, its certainly a tough problem, but RenderMan was designed to be renderer independent, so it seems to me that this task should go somewhere else in the pipeline. Of course we could debate all day about this one 8-) At least we agreed on most of the points.... See ya 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-)