Hooray! One of my blog posts was featured on stage32.com which is the world’s largest social network and educational hub for film, television & theater creatives. Thanks Julie and Richard Botto for featuring me on Stage32!
A little post on rendering and path tracing.
After years of work with shaders and lighting frameworks in RSL I had hard times to fully understand the new Renderman RIS framework which seemed fractured and not transparent compared to RSL environment. It took me some time to get a grasp of the system and I feel like there is a lot more to discover.
I decided to share my little diagram which gives a general idea about how the data flows inside RIS. It might look simple, but I wish I had this diagram before I started digging the RIS framework.
It was a big surprise when I found out that the shading happens outside of the “shader”, opposed to RSL equivalent where the final shading is defined in a shader itself. Perhaps that is the reason why shaders in RIS aren’t called shaders anymore. Now those are BxDFs. I think Arnold and Cycles devs call it a closure. The closure is a concept which comes from OSL (Open Shading Language), basically it is a description of how the surface scatters light. As BxDFs the closures do not calculate the final surface color.
3delight render devs were smart to wrap the concept of closures inside a single function called trace() leaving the final integration exposed to the shader writer. The 3delight’s trace() function provides several BSDF descriptions out of the box. It helps to avoid heavy math and gain creative control over the final result.
To find out more about the actual RIS coding and how it compares to RSL I conducted a little research on RIS C++.
To sum up my post on the path tracing I attach an interesting and very illustrative video about path tracing. It gives the basic understanding of what happens under the hood of path tracers. I really loved the tone and the mood of the video. Enjoy!