Fast renders


A recent trend is to use heavy path tracing algorithms, which yield fantastic results. Renderers such as Arnold, Octane, and Cycles are great examples of quality and photo real rendering. Some years ago, I had the pleasure to beta test Arnold MtoA render and do some developments with Open Shading Language for Cycles.  Arnold and Cycles are great production ready renders, while Arnold is a popular solution for A class Hollywood VFX shows. Cycles is nonetheless a flexible open source fast GPU/CPU path tracer.Despite the ease of use and realistic results of the renderers, I still prefer traditional Renderman REYES workflow with a bit of programmable ray tracing. Here is why and some examples:

Fast and 100% controllable at the lowest levels.                 

99% of my work is CGI animation and not still renders. As complexity and length of animated shots grow,so does render time.The best way to reduce render time without sacrificing quality is to tell the computer where it can avoid costly computation, where it can approximate the results, or even reuse previously calculated data. Here are some still frames from a 3 minute long project for the Eurasian Bank.

Most of the shots contained futuristic tunnel with one hundred big ceiling diffused lights, shiny reflective bikes driving inside the tunnel, lots of motion blur and DOF effects—a daunting task for any renderer. As the studio was busy with other projects, there were limited human and computer resources available.In order to meet the deadlines and client expectation, I had to come up with a fast rendering solution. First I tried a straight approach where I placed dozens of area lights, activated one light bounce and motion blur and just hit the render button. It took 20 minutes to render a noisy image.Not bad.However, I knew that I had to render 4500 frames. If a single frame took 20 minutes to render it would take 1500 hours to render 4500 frames, which is not bad if you have a huge render farm and plenty of time. I only had three days to light and render the whole project. Moreover,during those days a client could make changes and comments, so I had to setup the rendering in a way that we could make adjustments and get quick results without spending too much time on rerendering. The solution was the Programmable Raytracing.

To accelerate the rendering of the environment I wrote a special shader. Basically the shader could bake necessary render information in a bitmap. It didn’t calculate lightmaps and shadows, since any change in the lighting would require full recalculation of the baked information. Instead, the shader fired the rays that probed the surrounding objects and baked the resulted bent normals and geometry occlusion into a bitmap file. It is an old technique that was first used by ILM on the movie Pearl Harbor.This was a groundbreaking achievement in those days.This technique allowed the use of HDRI lighting with proper shadowing and ambient occlusion without a single ray cast. The bent normal map encoded occluded and unoccluded 3d vectors, which originated from the surface of a rendered geometry. These vectors allowed sampling of HDRI lighting, taking into account surrounding objects. The second map was an ambient occlusion which attenuated the HDRI exposure. So no matter how I moved and changed the lights, the bent normal and occlusion maps would always provide a plausible, realistic global illumination solution in no time.


So the programmed shader allowed cutting down the render times by more than one order of magnitude. Twenty minutes became 1.5minutes of render time.

The second large optimization was done for raytraced reflections.The physically based shader that I wrote and maintained for several years was smart enough to decide how to trace reflection and interreflections. It could fire a ray and return a user-specified color, omitting any expansive shader calculations.Or,it could evaluate a specific bit of a code of a reflected surface, calculating the simplified diffuse and specular shading models. Moreover the shader could reduce the overall number of rays if SSS surface had been traced. That brought down rendering time for bikes by another order of magnitude, opposed to brute force Monte Carlo reflections.


The Programmable Raytracing provides ultimate control over the rendering process. It allows implementing custom methodology that will best suit specifics of a project. It gives the freedom to develop unique rendering solutions and be independent from renderer limitations. It is the ultimate in terms of strength and flexibility.

Some look dev stills for a client and the video



7 thoughts on “Fast renders

      1. Why OSL over C++? Few questions more: Does C++ have full support in RenderMan? Because OSL doesn’t have, can you give me cons and pros for C++ and OSL, and links for tutorials how to use both languages in RenderMan?

        Thank you.

        1. This link might help u out

          I’m not sure if Renderman fully supports OSL. OSL is easy and it is specifically designed for shading. C++ is a general purpose language. It requires much deeper knowledge of low level programming, memory management etc

          1. No it supporst only partialy OSL, but why I don’t know. But on long term what is better to learn OSL or C++ (probably stupid question)?

          2. I can’t answer this question it all depends on your goals. C++ is a whole science and it is a software developer’s territory.

Leave a Reply

The reply will be processed within a day