PDA

View Full Version : Pixar releases Renderman Pro Server 13


mustique
05-31-2006, 08:41 AM
Multithreading + 3Xspeed for raytracing! :)

Here's the link to the press release

https://renderman.pixar.com/products/news/rps13.0_release.html

playmesumch00ns
05-31-2006, 01:02 PM
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!

a23
05-31-2006, 01:16 PM
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.

Thanks,

Andy

Bonedaddy
06-01-2006, 12:46 AM
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.

ajsfuxor
06-01-2006, 01:30 AM
Anyone have any idea when this version will filter down to Renderman for Maya?

Titus
06-01-2006, 01:47 AM
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.

brick maps are a sort of voxels containing texture information.

Here's something the guys at Pixar told about PRMan 13 last year (http://deathfall.com/article.php?sid=5608).

beaker
06-01-2006, 02:44 AM
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?Think of it almost as a multiresolution(3d Mipmap) point cloud that can hold something along the lines of vertex colors in video games.

beaker
06-01-2006, 02:48 AM
This explains it more visually
http://www2.imm.dtu.dk/visiondag/VD05/graphical/slides/per_henrik_christensen.pdf

Bonedaddy
06-01-2006, 02:54 AM
brick maps are a sort of voxels containing texture information.

Here's something the guys at Pixar told about PRMan 13 last year (http://deathfall.com/article.php?sid=5608).


Right, I think I get that. If I'm understanding this paper (http://graphics.pixar.com/IrradianceAtlas/paper.pdf) 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."

Per-Anders
06-01-2006, 02:56 AM
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?

NORG
06-01-2006, 05:44 AM
Right, I think I get that. If I'm understanding this paper (http://graphics.pixar.com/IrradianceAtlas/paper.pdf) 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."

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...

Bonedaddy
06-01-2006, 06:48 AM
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.

tweeeker
06-01-2006, 06:48 AM
Right, I think I get that. If I'm understanding this paper (http://graphics.pixar.com/IrradianceAtlas/paper.pdf) 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."

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.

T

Jozvex
06-01-2006, 07:22 AM
Mmm, all sounds pretty nice indeed!

westiemad
06-01-2006, 08:30 AM
oooh yes, I've been looking forward to this in a while.

playmesumch00ns
06-01-2006, 09:27 AM
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.

Thanks,

Andy

Yep, no raytracing needed.

From what I can tell it's basically the same technique as Chapter 14: Dynamic Ambient Occlusion and Indirect Lighting (http://download.nvidia.com/developer/GPU_Gems_2/GPU_Gems2_ch14.pdf) 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!

fasteez
06-01-2006, 10:04 AM
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 ^^

thethule
06-01-2006, 02:52 PM
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!

Marc

a23
06-02-2006, 10:34 PM
Thanks, I really appreciate it, sounds really great.

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

Andy

Yep, no raytracing needed.

From what I can tell it's basically the same technique as Chapter 14: Dynamic Ambient Occlusion and Indirect Lighting (http://download.nvidia.com/developer/GPU_Gems_2/GPU_Gems2_ch14.pdf) 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!

shehbahn
06-03-2006, 12:44 AM
>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...

dmaas
08-13-2006, 10:39 PM
Point-based occlusion is the "real deal." It's about 3x faster than ray-tracing, and looks better. I haven't encountered any situations where it doesn't work yet.

xen_ninja
08-14-2006, 12:22 AM
Point-based occlusion is the "real deal." It's about 3x faster than ray-tracing, and looks better. I haven't encountered any situations where it doesn't work yet.
care to share more??

CGTalk Moderation
08-14-2006, 12:22 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.