Reversed Normal

I have been investigating solutions for real-time global illumination over the past few weeks, and thought I might share some of my thoughts on a potential approach to this problem.

To create a global illumination effect for static geometry and lights is relatively easy. One must simply bake the lighting information into a series of light maps which are then multiplied into the scene when rendered in game. The lighting rigs can be as complicated as you like, and can leverage whatever cool features your DCC tool has, provided the lights and the geometry in the scene never change.

Dynamic geometry presents a bit of a problem. Light maps won’t do because when the object moves from it’s baking position, the values from the map are no longer valid. Though some global illumination effects can look passable even when not accurate (ambient occlusion, for example), in most cases, this is unacceptable. The most common solution for achieving low-frequency global illumination effects on dynamic objects is to approximate the environment’s lighting using spherical harmonic approximation, a technique similar to Fourier signal approximation.

Continue Reading »

In order to render volumes in Renderman, one has two options. The first is to render a large amount of points (several million to get good results) or ray march through a volume using some density function to compute the volume’s accumulated color and opacity along the ray. In this work, I am attempting to produce a hybrid approach. By sampling density from a relatively sparse point cloud (several thousand points rather than several million) in a ray marching shader rather than a density function, volumes can be modeled or simulated in external applications and rendered in Renderman using Ray-marching. See older posts on the subject for more details.  The following is based on Ian Stephenson.

How do we sample density from a cloud of points? Given a position in the cloud, we need the number of points within a given radius. Dividing this by the volume sampled, density can be approximated. Renderman has two data structures for storing point data: point clouds and brick maps. Brick maps are the most attractive solution, as they store point data in an octree for easy spatial look. However, the function for accessing data from a brick map from within a shader, texture3d(), returns an interpolated value of all the samples within a given radius, not an accumulated one. This necessitated the creation of a custom data structure and interface in the form of a DSO shadop.

Here are the source files:

particlemap.h

particlemap.c

pmapdso.c

converter.c

A simple volume shader samples the kd-tree while ray-marching. Here are some preliminary renders:

Each of these renders uses a increasingly large sampling radius when calculating density from the kd-tree. As the sample radius increases, the volume begins to converge to a shape with hard edges along what I think are the kd-tree cell boundaries. I’m still investigating how to fix these artifacts. More later.

I’ve been working on a project for my Italian renaissance art class for the past few days, which not surprisingly considering my interests, involves a computer, Wiimote, funny sunglasses, and some infrared LEDs.  I’m trying to recreate an early Italian renaissance painting (from the likes of Fra Angelico or Piero Della Francesca) with a new spatial component - parallax.  The Italian virtuoso painters made great strides towards perfect spatial representation, but were limited to a two dimensional picture-plane - something that can be solved with some cool electronics.   I’m sure Brunelleschi would have loved this stuff.

The idea is simple, and is based on the work done by Johnny Chung Lee with Wiimote head tracking.  With a stationary Wiimote and two LEDs mounted on the side of a pair of cheap sunglasses, Johnny’s software can calculate the ‘position’ of your head and from that derive a projection matrix.  I plan to cut out pieces of paintings and offset them along the z-axis, hopefully producing some nice 3D effects when the viewer moves his or her head around.

For those of you out there wanting to try this Wiimote head tracking thing, I’ll warn you that I ran into some technical difficulties before I actually got it to work.  First, getting the Macbook Pro bluetooth card to play nice with the Wiimote under XP is neigh on impossible.  Secondly, the bluetooth drivers and software everybody seems to be using for this sort of thing, a horrid bundle of trash called Bluesoleil, doesn’t work either.  After beating my head against this stuff for a little while, I went to Best Buy and picked up a Kensington USB bluetooth adapter for about $30.00.  I followed the steps in this tutorial and got it to work (actually, I lost another several hours because the damn Wiimote was out of batteries and I didn’t know it - thanks Dave).  I haven’t finished putting together the infrared shades yet, so I used two candles (candle flame emits infrared light, conveniently) placed about 10 centimeters apart to approximate a Wii sensor bar.  I would not recommend putting this on your head.

More on this later.