PDA

View Full Version : beginning renderman question


-Vormav-
09-01-2005, 02:55 AM
Hey. I just picked up the Renderman Companion (expecting the Advanced Renderman book to come in the mail any day now, too), and so I've started going through it.
The first thing that's throwing me off is that the book is working in C to describe scenes. And while I would expect that much for developing renderman shaders, I was under the impression that scenes were typically described through simple RIB files.
Is this way of describing scenes just an older method that eventually got replaced with RIB files (this is an old book afterall, so such changes to the rendering approach wouldn't surprise me), or is it supposed to serve some other purpose (building your own renderman-compliant renderer, perhaps)? Or if it's still commonpractice to describe scenes in C...what would you compile these as in order to run them through a renderer (I'm just setup with Pixie right now, if that matters)?

Hope I don't come off sounding too noobieish. :wip:

Ayam
09-01-2005, 06:38 AM
Hi,

this question is coming up now and then and is therefore
answered in the RenderMan FAQ:
http://www.faqs.org/faqs/graphics/renderman-faq/
"What's the difference between the procedural interface and RIB?"

In short, modeling programs use the procedural (C) interface
for export to RenderMan renderers,
people can write RIB files (syntax is explained in the book you are
awaiting or may be learned from example RIBs and RC easily).


best regards,
Randolf,
--
http://www.ayam3d.org/ Reconstruct the World!

fxjeane
09-16-2005, 04:49 PM
Most programs I have used that export renderman always use RIB as its interface. Why? because there are a lot of tricks or fixes you can perform on an ASCII RIB file with simple Perl or Python filters (or any other language). This can save a lot of time in RIB re-generation and it also helps when you are trying to debug scenes.

The companion is a good book to have as reference for stuff that is not covered in ARMan, but most of its information is outdated. ARMan will get you up and running.


Cheers
Rudy

rendermaniac
09-17-2005, 11:57 PM
When the RenderMan Companion came out (1989) the RIB format didn't exist, so the C API was the only way of accessing RenderMan. Since RIB appeared everyone uses it as it is easier to use.

The only exception would be things like the RenderMan for Maya plugin which probably calls the API directly. Of course the downside of this is you can't get in and hack the RenderMan commands yourself then.

Simon

soopagenius
09-18-2005, 05:49 AM
The only exception would be things like the RenderMan for Maya plugin which probably calls the API directly. Of course the downside of this is you can't get in and hack the RenderMan commands yourself then.
Simon

Actually, liquid, the popular open source Renderman plug-in for Maya, will emit RIB files, and MTOR certainly must too.

Also, "calling the api directly" actually results in a RIB file being generated if, for instance, a file name is passed to the api call RiBegin.

The api still serves a purpose (for instance, it's what actually executes the commands in the RIB files;-). I wouldn't recommend the using C bindings, though, unless you really need to use C for some reason. The Python bindings are much easier to use, especially for newbies (check out cgkit.sourceforge.net if you are interested).

I would say that the principal advantage of using the api is that you are talking to the renderer in a real computer language, replete with variables and iteration and branching and the lot. RIB files are great and all, but they can grow freakin' huge -- 100s of MB and more -- in typical production situations. Usually a procedural description is dramatically more compact.

Also, if you want to generate a RIB file in a program, certainly you can just directly stream out RIB commands with print statements, but it is probably better to generate your RIBs via the api -- the api has a better chance of getting the RIB syntax right than you do. Also, if you use the api, your program has the option of talking directly to the renderer with no bulky RIB intermediate, if you so desire.


Kevin Atkinson

Mauritius
10-17-2005, 08:51 AM
Actually, liquid, the popular open source Renderman plug-in for Maya, will emit RIB files, and MTOR certainly must too.

Also, "calling the api directly" actually results in a RIB file being generated if, for instance, a file name is passed to the api call RiBegin.

That is only so if the renderer can't handle API calls directly outside a DSO. Some renderers (e.g. 3Delight) can do so very well. Calling RiBegin(NULL) will make the 3Delight Ri library build the scene in memory, thereby omitting any disk i/o and RIB parsing overheads.
Think of all the floating point numbers that get converted into text (thereby potentially loosing precision), then get parsed and converted back!
Two years back a friend of mine and me wrote an AfterEffcts plug-in -- just for giggles -- that makes use of this fact. We would get 10fps on a subdivision surface resulting from a 1,000 polygon object at a shading rate of 20 and 3x3 pixel samples at 640x480 viewport size (that's still some 100,000 u-polys!).
Pretty impressive. Given 3Delight's speed improvements particularly with sds and the advances in CPU power since then, I'd say you can get 20 fps on much denser geometry (with lower shading rates) today.

The api still serves a purpose (for instance, it's what actually executes the commands in the RIB files;-). I wouldn't recommend the using C bindings, though, unless you really need to use C for some reason. The Python bindings are much easier to use, especially for newbies (check out cgkit.sourceforge.net if you are interested).
The problem with Python is that it parses the entire file and compiles it. Try that with a 1 GB scene description file. Additionally parsing Python is 10-20 times (!) slower than parsing RIB. Even leaving memory requirements aside, it is not practical to have scene parsing times in the range of several minutes add to the insane RIB-gen. times we have on most productions these days; let alone the actual render times.

I wrote a Python C Ri binding based on Gelato to use as a RIB replacement here as we liked what they did with Pyg. I dropped it as it became obvious that it isn't feasible for production level scenes. On a sidenote, the Gelato manual lists exactly these problems -- for me Pyg is a nice marketing gag for the feature list -- nothing more.
I opted for LUA instead and all looks good so far. I'd prefer Python over Lua any day syntax & features wise, but for a production useable scene description format, it fails on too many important points. :)

Cheers,

Moritz

rendermaniac
10-21-2005, 09:09 AM
Yeah what Moritz said ;) I think you can pipe to a renderer with RIBegin too, although I may be wrong as I have never tried it. eg. RiBegin("prman") although RI_NULL seems a better approach.

Creating LUA bindings sounds interesting. It would be nice to have more runtime control without having to produce C code and compile it. User Attributes and conditional RIB give a glimpse of the potential here, but either it doesn't go far enough if you want more runtime control (my view) or is a slippery slope to making RIB into an interpretted language (I can see that point too).

So does LUA do the same thing as Python, just with much less overhead? Itr does seem a pretty spartan language. Or is there a fundamental difference?

Simon

-Vormav-
10-21-2005, 09:18 AM
Thanks for all of the replies. :)
As long as this thread still has a little life left in it, I've got another question to throw your way:
In the renderman shading language, how do you access the individual compenents of a color (so, separately accessing the r, g and b values). I dug through the books, but didn't see anything that showed this. I've tried things like color->r as well, but the compiler always complained.
Someone told me that they thought it would be accessed through color.r, but that seems like it would conflict with the SL's dot product syntax.
It's not that big of a deal; I can always just multiply by different colors to get the right components if need be. But I'm sure Renderman has some simple, direct way of accessing these values.

playmesumch00ns
10-21-2005, 11:26 AM
float r = comp( mycol, 0 );

color green = color( 0, 0, 0 );

setcomp( green, 1, 1 );

-Vormav-
10-22-2005, 06:16 AM
Perfect. Thanks. :)
Kinda strange that the Advanced Renderman book doesn't mention those functions at all.

Ayam
10-26-2005, 05:25 AM
It does.
See page 177, "Simple Built-in Functions", "Color Operations"...

best regards,
Randolf,
--
http://www.ayam3d.org/ Reconstruct the World!

-Vormav-
10-26-2005, 07:50 AM
Eh, well they should list it in the index then.

rendermaniac
10-26-2005, 08:47 AM
Unfortunately the index isn't the best part of ARman. However Chapter 7 - Introduction to Shader Language has all the general functions that you need to know. Anything newer or renderer specific - consult it's documentation.

Simon

playmesumch00ns
10-26-2005, 12:07 PM
Yep. The Quick Reference/RSL Functions reference in the prman manual is fantastic

CGTalk Moderation
10-26-2005, 12:07 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.