Reversed Normal

As part of my RenderMan for real-time research, I have for some time, been working on a solution for generating spherical harmonic coefficients from arbitrarily complex lighting environments for use in real-time. While not completely finished with this, I have some promising preliminary results.

First, some background. Spherical Harmonic lighting is a method for computing complex low-frequency lighting solutions in real-time by pre-calculating a series of SH coefficients which when used in a linear combination of SH basis functions, can produce an approximation of the original lighting. For more details on this process, I would direct you to Robin Green’s Spherical Harmonic Lighting: The Gritty Details. I drew much of my code from this paper.

Continue Reading »

So the other day, I got the urge to do some retro-programming. What better platform, I thought to myself, than the Nintendo Entertainment System. Unfortunately, for the beginner, programming even a very simple ROM and running it in your favorite emulator can be challenging. So here now is my small guide to getting started.

Continue Reading »

Those familiar with creating 3D assets for games or other real-time applications are probably familiar with the process of baking static lighting information as a series of maps which are combined with dynamic light contribution at runtime. Precomputed light maps can represent even the most complex lighting rigs in real time, provided neither the geometry or the lights change.

These maps can be easily generated by popular modeling packages, so why use RenderMan? Using RenderMan to precompute lighting information comes with several distinct advantages. First, one may leverage the power of a RenderMan renderer, which in many cases can be obtained for free. You don’t need Maya or 3D Studio Max to make nice light maps. Secondly, if a generic interface is created between game data (your proprietary scene files) and RenderMan, you could easily integrate a RenderMan system into your existing code and tools. Finally, while light maps can easily be generated by Maya or Max, neither of them support compressed HDR output, which I plan to implement. Also, they cannot create spherical harmonic data for dynamic geometry - another issue I plan to address. See my other post on the subject for more information.

Continue Reading »

The RenderMan Shading Language is very feature rich, but at some point, you may need to extend the language to do something it doesn’t do out of the box. To do this, you must write a DSO Shadeop.

I have written several of these using PRMan’s SDK at school, but when it came time to write one at home using 3Delight on my Mac, I was at a loss. The 3Delight documentation regarding DSOs describes how to write a very simple one and compile it using the command line. Compiling stuff with the command line is cumbersome, so I worked out a way to do it with the XCode IDE.

First, I tried creating a compiling one of XCode’s C++ dynamic library projects, but was unable to link the resulting library in when it came time to compile the shader. The example in the 3Delight documentation compiles to a “.so” file (shared object, I assume), so I set about trying to create one with XCode.

Continue Reading »

When using the PRMan SDK for Windows, I ran into a strange linking issue. Linking against prman.lib and libprmansdk.lib caused about 100 undefined symbol errors. It took me a while to track down a fix (there is very little documentation for the RenderMan SDK). It turns out that the SDK links against wsock32.lib and iphlpapi.lib. Just add those in your linker settings, and you should be golden. I hope this saves somebody some time.

I was reading an article from a back issue of Game Developer (August 2007, I believe) wherein several prominent programmers were discussing a wide range of topics. Not surprisingly, the discussion found its way to the problem of multi-threading. One of the programmers described an approach which I found quite interesting and practical. Programmers at his studio designed systems (sound, rendering, physics, etc..) as if they existed in their own memory space (or with as little memory shared as possible) and that systems communicated not by calling each other’s methods, but by passing messages which are queued and handled by the system in a linear fashion. The memory bit is fairly obvious, but the message passing thing sounded really cool.

This approach decouples method invocation from method execution (much like Objective-C does) and feeds the messages to the system one at a time. This guarantees that the system will execute instructions in sequence. A little time on Google and I found that this idea is a very well established design pattern called the “Active Objects” pattern. I found a great example of this pattern implemented in Python here.

In the Active Objects pattern, a “passive” object is wrapped by an “active” one, which forwards message objects to it from a queue. Messages are generated and enqueued by a “proxy” object, which implements the public interface of the system and exists in the client’s thread. Once one of the proxy’s methods is called, a “future” object (I called it an AsyncResult object like in the Python example) is returned. Once the system has processed the message, the return data (if there is any) is placed in the future object to be retrieved and used in the client thread.

This pattern is by no means a silver bullet, but it helped quite a bit in my code-base by providing a generic solution to threading that can accommodate lots of different types of interfaces and special cases and which protects against race conditions without excessive mutex use.

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.

For all the great things Lua has done for my current game development endeavour, it is now proving to be a royal pain in the ass.

The problems began when I added a background loading system to load new scenes in a separate thread without interrupting play.  This all worked until it began loading Lua scripts.  At the time, there was a single Lua state (virtual machine) for all of the scripts.  This was awesome because communicating between scripts was extremely easy.  When the loading thread started adding new scripts to the Lua state which was currently in use by the main thread, however, things began to go horribly wrong.

This problem was easily solved by having one Lua state per script.  This also fixed problems with naming, as Lua has no notion of namespace.  Lua states are designed to execute in isolation, so communicating between them becomes extremely difficult.  Implementing game logic without entity communication is neigh on impossible.

There are a few potential solutions.  The first would be to construct some kind of message passing system on the C++ side.  When an actor wants to tell another actor something, it dispatches a message which is received by the actor on the next update and interpreted.  Another option would be to use Luabind’s call_function() template function.  This approach would require custom wrapper functions for each different function signature you’d need.

More on this later.