Pixar releases Renderman Pro Server 13


Multithreading + 3Xspeed for raytracing! :slight_smile:

Here’s the link to the press release



This is the best release for a very long time.

The best thing for me is the approximate colour bleeding. Flicker-free and insanely fast. We don’t neeeed no steeeenking raytracing!


Hey there playmesumch00ns,

can you elaborate a bit more? Does the approximation work without raytracing? How’s the raytrace-shading-eval-speedup in real production? Any other things to mention that don’t show up in the press release?

Lot’s of questions I know, but you’re one of the proficient PRMan users on this forum.
Of course others are welcome to elaborate as-well.




Could someone explain the “brick map as geometry” bit to me? I did a google search and perused graphics.pixar.com, but couldn’t find much. Is that using multiple versions of tesselated geometry, held in a brick map-type structure, for LOD? Or something else?

Also curious to hear about the approx. color bleeding.


Anyone have any idea when this version will filter down to Renderman for Maya?


brick maps are a sort of voxels containing texture information.

Here’s something the guys at Pixar told about PRMan 13 last year.


Think of it almost as a multiresolution(3d Mipmap) point cloud that can hold something along the lines of vertex colors in video games.


This explains it more visually


Right, I think I get that. If I’m understanding this paper correctly, it can also contain some shading information, like irradiance. And, if I extrapolate correctly, it may have something to do with deep shadows? However, given this definition of brick maps, I’m still not sure how that translates to “brickmaps as geometry.”


so… that’s different from a standard lightmap how? just that it’s an octree rather than a voxel grid? or merely different terminology same technology?


Brickmaps can store whatever you want. In Per’s paper, he is using it to store irradiance from a photon scattering pass. The jist of his results is that brickmaps are a faster and way more memory efficient than a standard kd tree. Most td’s though, use brickmaps to store data like occlusion, shadows, or reflection.

Just to clarify things, a brickmap is a “3d, sparse, mip-mapped, octree”, which basically means it’s a fast, memory effecient, 3d texture (as opposed to point clouds / kd trees, which are fast, but are memory hogs and hard to filter). The advantage of brickmaps over baked 2d textures is that they are idependent of UV’s and able to be blurred spatially (3d blur). Using spatial blurring instead of ray tracing can get you killer speed wins (think rough reflections or sss).

As for “brickmaps as geometry”, this is a feature that allows you to render a brickmap directly, rather than read it from a shader. The data could come from a tesselated mesh whose color and opacity has been baked into the brickmap, or from something completely different, like a fluid sim. The main advantage seems to be lod: Take a complex object, like a pine tree, and bake it into a brickmap, then set dress the brickmap into the shot rather than the original object. When it comes time to render the brickmap in the distance, only the highest levels of the mip map will be needed and you save a ton of memory (no need to load all those bloody vertices).

I’ve spent way too much time with brickmaps…


Paul, that sounds pretty amazing. I’ll have to give that a go next time I’m in a position to monkey around with PRman a bit. Thanks for the info.


Prior to v13 that’s mostly what brickmaps were used for - a 3D file format for shading info that had the benefites of mip-maping and load on demand. Multiple ‘channels’ of different types (colors, normals, points etc) can be contained in a single brickmap. Version 13 allows brickmaps to be rendered directly. So roughly speeking, each voxel from some appropriate level in the brickmap is diced into a micropolygon and resolved by the hider in the same way as any other primitive such as subd or polys.

It’s pretty cool because you get automatic level of detail. Create a brickmap of some ultra high rez geometry and you can render it in linear time at any size on screen, with correspondingly low memory usage.



Mmm, all sounds pretty nice indeed!


oooh yes, I’ve been looking forward to this in a while.


Yep, no raytracing needed.

From what I can tell it’s basically the same technique as Chapter 14: Dynamic Ambient Occlusion and Indirect Lighting from GPU Gems II. You bake the direct lighting from your surface to a PTC, which basically creates a cloud of coloured disks representing the scene. Then when you render the final frame it calculates the transfer between all those disks and your surface to give you 1-bounce GI (and hence ambient occlusion). It’s kinda like radiosity, and it’s very, very fast.

I can’t say enough good things about this version. It’s like getting 3 releases all rolled into one. There’s only one production renderer on the market, and now it’s got extra sexy features!


u got the true sentence lol

pixar’s on his way to move you to his market departement ^^


You know what i think? I think it’s quite funny that i read articles like this even though i havent got a CLUE what any of the big words mean. I mean, i have been doing Cg for 8 years now and like to think i know a little about it but those renderman terms mean absolutely as much to me as Mongolian poetry. All i can do it sit here and go “sounds cool”. Now come on, tell the truth… Can Brazil and Vray do a lot of this stuff, they just don’t have fancy words for it?

Octree, schmoctree!



Thanks, I really appreciate it, sounds really great.

Another thing, are there any major changes to RSL and what about the plug-in API?



>Another thing, are there any major changes to RSL

there are a few minor changes - the compiler is a tad more restrictive on certain rules (un-initialized variables / type checking - mostly small stuff that forces you to write cleaner shaders)

>and what about the plug-in API

it’s APIs : the old shader plugin API still exists for backward compatibility but there is a new one that is now thread-safe. it’s gone through a few revisions lately, but IMHO the final product is very solid. rewriting all your code to be thread safe on the other hand…