View Full Version : RenderMan compliant?

09 September 2003, 04:37 AM
greetings all
doing some research on RenderMan API & I need some suggestions for a compliant renderer (preferably free of charge). I know I have a couple of options here... Been over to RenderDotC, & it said the free version was "crippled by resolution."
Im looking for at least 640 x 480, running winXP, & using geometry from Maya.
please help

09 September 2003, 04:59 AM
There's a renderer called "Angel". I believe it is renderman compliant. Try looking for "Siren", and "Aqsis" also. 3Delight may be free, but don't hold me to that. BMRT may still be floating out there. You can get a demo of AIR and check out its capabilities. I know you're looking for freeware, but this renderer is pretty cheap for students and has a well rounded feature set. The price tag was around $130 about a year ago....

09 September 2003, 06:44 AM
yeah, i'd probably use something free until i get further into renderman. i've looked at 3delight, & was just kinda wanting to hear others' experiences w/ any of the free ones.

09 September 2003, 10:59 AM
Pixie (
comes with full source code !!!



09 September 2003, 12:55 PM is a good REYES (like PRman before it got raytracing) based renderer. Plus the forums are very useful for support/suggestions. I have heard that 3Delight is a bit faster though.

09 September 2003, 02:17 AM
From the free ones, 3Delight is closest to PRMan in features and speed.
It is actually a commercial product that is continously developed by a team of professionals. It is also at the same time used in several facilities around the world for professional production.
It will sooner or later no longer be free of charge for commercial use though rumor has it that it will stay free for non-commercial use.


09 September 2003, 05:18 AM
much appreciated everyone. ill be working with 3delight

09 September 2003, 03:45 PM
Don't undercut Aqsis if you want to play with the Shading Language using it with SLBuilder is not too shabby. Personally I still use and love BMRT.

09 September 2003, 04:04 PM
3Delight appears to be the most modern, stable and complete of the free RenderMan renderers - at least, in my epxerience.
Aqsis has some very promising features too but I found it not as stable as 3Delight.
Pixie - well - I never could get it to compile, neither on MacOS X nor on Linux/PPC. I might try on my Windows computer or Linux/x86 some day.
BMRT, if you can get copy of them, they're solid and proven but not up to date in terms of features. If you want global illumination or RiCurves for hair, BMRT won't do that.

09 September 2003, 06:07 PM
BMRT, if you can get copy of them, they're solid and proven but not up to date in terms of features. If you want global illumination ...

Not completely true: read this ... (

09 September 2003, 12:43 AM
Wops, my bad. Of course, BMRT do radiosity, how could I forget that? IIRC it's the modern things like photon mapping or area lights that BMRT is having problems with. (3Delight doesn't gather() either...)

09 September 2003, 12:53 AM
gather() is about shooting rays, not photon mapping or the like. An implementation supporting fancy stuff like photon mapping or irradiance caching (e.g. PRMan or Pixie) could support looking up this data implicitly when gather() is called, but it doesn't have to.

I'm unsure why 3DL does not support gather -- even w/o irradiance caching or photon mapping, gather() makes sense (e.g for ambient occlusion).


09 September 2003, 01:48 AM
Originally posted by stew
Wops, my bad. Of course, BMRT do radiosity, how could I forget that? IIRC it's the modern things like photon mapping or area lights that BMRT is having problems with. (3Delight doesn't gather() either...)

I'm pretty sure the last version of BMRT did do area lights, as well as photon mapping and irradiance ray tracing (global illumination).
Not too shabby. The main things it didn't do were depth of field and motion blur (well it had them before 2.6 - removed for legal reasons). I don't think it did curves, subdivision support worked but was a little experimental. And I think there was an extremely experimental blobbie support (not in RIB though). BMRT had radiosity ages ago - that's some of the oldest tech in BMRT!

09 September 2003, 08:10 AM
OK, I'm going to admit that I have hardly any experience with BMRT and am going to shut up for now. :shrug:

AIPh Pretzel
10 October 2003, 03:37 AM
So, as an overview, where does AIR come into play in the big picture? It's not free for a reason ... so it's up there. What other "pay-for" options do I have?

10 October 2003, 09:08 AM
3Delight will stop being free next year for commercial users.
RenderDotC has always been commercial.

AIR, though RenderMan compliant, is not a REYES renderer btw.


10 October 2003, 06:01 PM

I'm writing a plugin for 3ds max to hook 3ds max up to RenderMan compliant renderers. In the process I've used 3Delight, AIR, Aqsis, BMRT, and PRMan.

I found 3Delight fine to use, except that I can't get a shader with a DSO in it to compile (it worked fine with AIR, and this is using 3Delight's instructions!). Also (and this is a problem with PRMan as well) there are visible seems between some polygons that butt up against one another . I am using separate Polygon statements, so this problem might go away when I move to PointsPolygon with facevarying. Who knows.

AIR I've found easiest to use. Whenever I added a feature to my plugin, AIR was usually the first renderer to give good results. I recently messed up my installation, though, and now shadow maps don't work.

Aqsis is slow, but AFAIK they haven't even started optimizing it yet, so that should change. I had a problem with using their shader compiler, but I call it from my program to execute it, so it shouldn't be a problem for most users.

BMRT seems to work fine. I couldn't get motion blur to work yet, but I haven't looked at BMRT's documentation yet. Also BMRT (and 3Delight, actually) gives me strange results using shadow maps. I think I need to play with the bias.

I just got an evaluation license of PRMan, so I can't say much about it yet. It seems to be the fastet of the renderers.

Hope this helps,


10 October 2003, 06:19 PM
henning -

IME it's better to do polygons not as separate entities but as RiPointsPolygons where possible.

Are you linking against the renderers or are you exporting RIB files?

How do you get an evaluation license for PRMan? I am writing a RIB exporter for Poser, and it'd be great if I could test it with PRMan some day.

10 October 2003, 07:31 PM
I know pointspolygon is better, but when I wrote that code I didn't know about facevarying. Without facevarying, texture coordinates in pointspolygon wouldn't come out right. It's on my todo list to switch over.

I'm sending you an e-mail about Pixar.


10 October 2003, 08:51 PM
Polygon(s) is/are the wost primitve, if you use a RMan compliant renderer. They are optimized to render everything but polygons -- AIR as a non REYES renderer is a clear exception here,

I suggest you add an option to your plug-in, to render all polygonal geometry as subdivision surfaces. All you have to do is to replece the RiPointsPolygons() call with one ro RiSubdivisonMesh ("catmull-clark",... ).
This requires to check that the geometry is manifold beforehand -- not that hard to do though.


10 October 2003, 09:48 PM
Yes, RenderMan isn't great at polygons. However, 3ds max is primarily a polygon modeller, so I have to deal with them.

I do allow geometry to be output as subdivision surfaces at the user's discretion. They come out quite nice. :)

What is manifold geometry?


10 October 2003, 01:49 PM
BMRT 2.6 doesn't have motion blur (or depth of field) due to patent issues with Pixar. So there's probably quite a good reason you can't get it to work ;)

Originally posted by henning
BMRT seems to work fine. I couldn't get motion blur to work yet, but I haven't looked at BMRT's documentation yet.

10 October 2003, 03:27 AM
And actually, I also found out that I only needed to set pixel samples to something >1 for AIR motion blur to work.


10 October 2003, 05:48 PM
Yep, they too out the motion blur and Depth of field, though if I remember correctly they said there were some technical issues ( we all know the truth though) BMRT last version did handle Photon Mapping and Monte Carlo type Global Illumination as well as an older mehod of doing irradiance that they had in previous versions, it is sad that another version never came out because they were going to take out the older method out ( to much memory used in this method also it required a certain amount of patch resolution for it to work)

10 October 2003, 10:29 PM
Sory for being picky tonight but the old BMRT global illumination method was radiosity the new one irradaiance (quasi monte carlo ray tracing). Radiosity works on energy transfer, needs to tesselate the geometry into a mesh and can only do diffuse lighting.

Irradiance (different from radiance - important difference! although I always confuse em) uses quasi random sampling of the hemisphere above the object to work out the light falling onto that surface. As it point samples it is geometry independent. (Radiance is the opposite - ie the light being emitted from the light source rather than being recieved at the surface).

Sorry to split hairs but a programming forum should strive to get definitions correct!

PS I bet someone will correct me now! ;)


10 October 2003, 03:44 PM
Actually , you are right. Sorry I wasn't really paying attention when I posted. But both methods still exist in BMRT2.6 so you can in theory use them both

CGTalk Moderation
01 January 2006, 03:00 AM
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.