[ Home ] [ Up ] [ Rendering Hair ] [ Displacement Mapping ] [ Visibility Maps ] [ Motion Blur ] [ Ray Tracing ] [ Programming ]

I spend most of my time at work programming. To many in the visual effects industry, being a programmer is a stepping stone to becoming a digital artist or taking on a managerial role. For me, it is a stepping stone to becoming a better programmer.

Here's a brief overview of some programming languages I use: 

C/C++

This is what I do most of my work with. The in-house renderer at Rhythm & Hues, as well as its many supporting libraries, are written in C++. I started programming in C back in my undergraduate days at U of T, and I started learning C++ shortly before I started at R&H. Though I am a big fan of C++ and prefer it over C, I am often frustrated by the fact that its implementation-hiding features like overloading and virtual functions make it a little too easy (even inviting) to forget what's going on behind the scenes; and that can make for inefficient code, especially when the code is shared among many programmers.

Here's a sample program I wrote that calculates barycentric coordinates. This formula is important in rendering, particularly with ray tracing. Given a 3-D point that is coplanar with a triangle, the barycentric coordinates of the point with respect to the triangle indicate whether it lies within the triangle, and how close it is, in relative terms, to each of the triangle's vertices. Very useful for both intersection testing and interpolation.

My implementation precomputes data based on the triangle and caches this to speed up all barycentric evaluations w.r.t that triangle. This approach is ideal when multiple points are processed for the same triangle. The memory footprint of the Barycentric object is reasonably small (it can be instantiated for either float or double precision), so one could store multiple objects, one per triangle, to use when needed.

Perl

I picked up Perl about 5 years after learning C++. I started using it to automate various work-related tasks, such as multi-platform builds, software releases, and CVS commits. As I learned more of this language, I began to wonder how I ever got along without it.

Although some have described Perl as an ugly language, I think it is extremely well designed and aesthetically pleasing. In some aspects of its design, I like Perl much better than C++. For instance, compare the implicit $_ in a foreach loop to C++'s rather ugly iterator construct for an STL container. Larry Wall wisely recognized that frequently used coding constructs, like iterating over a container, should not take dozens of keystrokes to use.

Here is genuinely useful Perl program I wrote and posted to sourceforge.net: an RPN calculator that handles vectors of arbitrary dimensionality. You can mix an match vectors of different dimensions on the stack. Operators require compatible dimensions but allow reasonable combinations, e.g. vector times scalar. You can store results in variables, read and write the entire stack to a file, and even define your own (simple) functions.

E.g. compute the angle (in degrees) between (1,2,3) and (4,5,6)

1 2 3

  0> 1 2 3

4 5 6

  1> 1 2 3
  0> 4 5 6

ang  (the angle operator)

  0> 12.9331544918991

This uses the built-in ang function, but we could have done the same using more basic operators as follows:

1 2 3
  
  0> 1 2 3
  
4 5 6
  
  1> 1 2 3
  0> 4 5 6
  
c  (copy last item)
  
  2> 1 2 3
  1> 4 5 6
  0> 4 5 6

n  (compute vector norm of last item)

  2> 1 2 3
  1> 4 5 6
  0> 8.77496438739212

/

  1> 1 2 3
  0> 0.455842305838552 0.56980288229819 0.683763458757828

s  (swap last two items on stack)

  1> 0.455842305838552 0.56980288229819 0.683763458757828
  0> 1 2 3

c

  2> 0.455842305838552 0.56980288229819 0.683763458757828
  1> 1 2 3
  0> 1 2 3

n

  2> 0.455842305838552 0.56980288229819 0.683763458757828
  1> 1 2 3
  0> 3.74165738677394

/

  1> 0.455842305838552 0.56980288229819 0.683763458757828
  0> 0.267261241912424 0.534522483824849 0.801783725737273

.  (dot product between last two items)

  0> 0.974631846197076

acos

  0> 12.9331544918991

Java

I undertook an interesting coding project in Java back in grad school, just as I was finishing up my thesis. I came up with a technique for efficiently rendering an ellipsoid by computing its outline and then constructing a fan of triangles to fill the outline. Out of this came an applet I posted to my web page, which rendered a twirling ellipsoid using both this new technique and a standard polygonal wireframe. I was pleased to see that my technique accurately rendered the ellipsoid's silhouette using far fewer triangles.

Unfortunately, I no longer have the source code for the applet, but I do still have the applet itself online at: