XRT is a raytracing based programmable rendering system for photo-realistic image synthesis built around a plug-in architecture design.


Teaching new tricks to an old dog

Posted: 29 Nov 2012 22:21
Tags: atmosphere gallery shader

This post is a sort of follow-up to the previous one. Although "Production Volume Rendering" only deals with voxel buffers, its reading has been inspirational enough for me to improve on XRT volume rendering. For now, XRT capabilities are based on RenderMan 3.2 atmosphere shaders1.

How atmosphere shaders work

This part is lifted from Pixar Application Note #20 available here

Atmosphere shaders are bound to surfaces, just like surface or displacement shaders. So you must have an object in the background for the atmosphere shader to run. In other words, pixels with no geometry at all "behind" them will not run any atmosphere shaders.

The general idea behind the smoke effects is to ray march along the incident ray I, sampling illumination and accounting for atmospheric extinction. Typically, this is done with the following algorithm:

Choose an appropriate step size for marching along the ray.
    total_len = length(I)
    current_pos = P;
    while total_len > 0 do:
        sample the smoke density and light at current_pos
        adjust Ci/Oi to add new light and extinguish due to smoke opacity.
        current_pos += stepsize * normalize(-I);
        total_len -= stepsize;

Volume shaders of this type can be very expensive. The computational expense is proportional to the number of iterations of the while loop, which is determined by the step size and the length of I. Therefore, it is important to choose your stepsize carefully — too large a stepsize will result in banding and quantization artifacts, while too small a stepsize results in very long render times.

A smarter shader

Fog light
Image Unavailable

This example, borrowed from the Gelato example set, features spinning gears in fog lighted with a spot light. Because there are holes and dents in the gears, parts of the fog are either obscured or lighted. This is the famous "god rays" effect.

On this kind of scene, the smoke shader example that comes with the Application Note #20 performs badly. The scene is quite large and there are many small details that requires a small step size to be properly caught. However, you will get a huge speed boost if you realize that the space outside the spot shape is not lit and does not need to be raymarched. If the shader is passed information regarding the spot shape (a cone here) and orientation, it can compute much tighter bounds for the raymarching algorithm and avoid useless steps in the dark void. First, the volume ray origin and position are transformed into the spot canonical space, then the new volume ray is intersected against the canonical cone shape (a mere second degree equation to solve).

You will get a better grasp of the "god rays" effect in the following animation:

You will find also this example and the companion video in the Gelato gallery.

Comments: 0, Rating: 0

Production Volume Rendering: a review

Posted: 13 Nov 2012 19:54
Tags: book pvr review

Finding your way through the computer graphics litterature jungle is hard: for most of the subjects, you will find a plethora of papers, all claiming to bring forward a decisive breakthrough. Most of the time, you will find that the brand new technique does not fit into existing rendering architectures, gobbles gigs of memory or that it adresses only a subset of your problem. Building a consistent rendering system is a difficult task.


"Production Volumetric Rendering: design and implementation" written by Magnus Wrenninge, a technical director at Sony Pictures Imageworks, is an attempt to clear the mess for a specific domain: volumetric rendering techniques. It does not try to describe all rendering techniques available in the litterature, instead, it focuses only on techniques used in the visual effects industry by people that need to deliver on budget and time. Following "Physically Based Rendering" path, it provides a complete rendering system (PVR) and centers the book around the source code.

The architecture Wrenninge advocates is deceptively simple: modeling tools fill voxel buffers raymarched by renderers. Of course, in the book, you will get a lot more details but, in the end, it does not get any further.

The book is divided in three main parts: basics, volume modeling, volume rendering. It may seem strange to discuss modeling in a rendering book but, while creating a polygon soup is quite obvious, building convincing volumes is not for the casual user. After all, one must fill these damn voxel buffers!

I have mixed feelings about this book. In all three parts, the technical content is really excellent and interesting (I particularly liked the chapters on the theoritical foundations of raymarching or on phase functions). The design choices are well explained and the example images (all computed with PVR) are a good proof of their validity.

However, the comments on the companion source code are frequently over extended when they address topics that deal more with programming than rendering. Even worse, they are sometimes redundant (for instance, the various discussions on attributes)1. The modeling part, even for my naïve eyes, is over simplified: there is no mention of fluid dynamics for example.

Finally, this book lacks a conclusion chapter: clues for the reader to extend and improve the system, hints to create animations, something to give the reader the compelling need to go beyond.

To summarize, the book could have been better but you will really get valuable information from it.

Interesting links

Comments: 28, Rating: 0