Mark "Monty" Montague

I've also included some notes on debugging techniques since it's hard to evaluate those skills from code samples.

Jray

In order to have a self-contained yet significant code sample, I decided to implement a ray tracer from scratch in Java. This took me about a week in my spare time.

Because this is intended more as an example of ability than a final product, there are a few intentional deficits. In particular, efficiency has been largely dropped for clarity, ease of programming, and need to fit into Java's rigid framework without too much contortion. To this end, I have left bounding surfaces completely unimplemented, and have skimped on optimization of memory usage.

It's also noteworthy that I have cast vectors in the "jvec" class to either location or direction subclasses, at a substantial object creation cost, in order to have better automatic error checking at compile time. This has caused some amount of ugly casting to get around Java's lack of templates and implicit polymorphism on return context, but was useful in rapid prototyping and reduction of suffering from minor "thinkos."

I'll also note that although I didn't see an appropriate use for Java interfaces in this project, I don't avoid them in general. Making "tracable" an interface rather than an abstract base class seemed too contrived, and violates the "is a" versus "has a" distinction.

Caveats

• camera and viewing parameters are still hard-wired. I didn't want to include them in the scene file on the theory that it would be nice to have separation of scene and view, like OpenInventor
• Triangles are only created flat-shaded, although code for normal interpolation exists
• Code relies Sun's jai class
• This is intentionally a stand-alone program, not an applet, since should it actually evolve into a useful ray tracer, it is desirable to be able to run distributed on a number of machines without being bound to a GUI environment
• Multithreading a raytracer at the granularity level of Java threads would be absurd for any number of reasons.

The code is available as a gzipped tar file or as individual files in a directory.

Tracedist, a Perl script which got into an Art Show

At the SIGGRAPH conference in 1995, when I registered, I was given an "Art Show Contributor" ribbon, much to my amazement. After I had suppressed the urge to go buy a black beret and complain that no one understood my work, I thought back on the events that led to this.

In fact, when Kurt Fleischer was working on a submission for SIGGRAPH 95, I offered him some help. What he urgently needed was the ability to raytrace the complex objects he could create with the 3-D version of his cellular textures in as little a time as possible. Since the raytracer he was using could run on several of our machine types (our lab has received workstation grants from HP, DEC, and IBM), we decided it would help a lot in making the deadline to split up rendering across these architectures.

So, while in one day or so, I hacked out a "quick and dirty" perl script which could cast off sub-images to the various machines with the right parameters, and then re-integrate them into the final image. I'm presenting it here because it's an example of the fact that I can use a combination of existing tools and new code to address an immediate need without sacrificing readability and reusability, and because it is officially my first piece I've had (implicitly) in an art show. Well, what the people in the art show saw was this...

... but my artistic contribution was really a perl script.

framedumpyuvi