Feel free to browse my archives. I hope you'll find the selection of source code, samples, demos and documents useful. Much of the content is rather old but should still hold value to many.

The email address in the older documents is out of date. If you want to reach me today, drop me a line at the following email address:

In the sections below, you'll find the more popular features along with a brief explanation.

You can find Inertia over on GitHub:

https://github.com/nettlep/Inertia

In the end, I had a set of fully documented playgrounds that covered almost the entire language (enough to certainly become productive.)

These playgrounds were intended to leverage your experience with C++/Objective-C.

You can find them over on GitHub:

https://github.com/nettlep/learn-swift

There are lots of features and although there is no documentation, full source code is included. This is an alpha release, and I'm not sure if/when I'll have a chance to revisit it.

Don't expect to view your radiosity results right away -- you'll either need to read/write the supported formats, or hack your own format into the source (get an example data file of the Cornell Box here.)

You can see some screenshots and examples here.

If you're curious how Radiosity works, I wrote a couple of documents that help explain the process in simple terms. They are Radiosity In English and Radiosity In English II: Form Factor Calculation.

Source code to an implementation (using software rendering).

A demo version that uses hardware rendering. Sorry, no source code for the hardware rendered version. Try this: set the mode to full-screen and enable vsync, then click OK and hit 't' on your keyboard to begin playback of a pre-recorded walkthrough demo that showcases some of the collision detection features.

In the early-90's, the popularity of 2D morphing was at its peak. The Complete Morph (a.k.a. CMorph) was one of the most popular of the bunch. CMorph was even a low-cost solution for many television production houses around the world.

I've released the source code. Since CMorph is DOS-based and requires the Watcom compiler, I've also made available the DOS binaries and an animation produced by CMorph; playable with DivX.

This is a small skeleton application, great for just playing around with graphics. It gives the programmer access to a frame buffer and a very simple architecture for displaying that frame buffer to the screen.

This project also includes an accurate software polygon renderer for those that need it, or those that are looking to understand the rendering process at a greater level of detail.

Source code for an experiment in accurate software rendering with persepective correct textures and w-buffering. Every 3D programmer has their own way to render polygons. Some are accurate, some are fast, some are both.

The enclosed source files are fully commented and describe the method that I've always used for rendering polygons in software. An emphasis is placed on accuracy, with as much speed as possible. Inside the source, you'll find comments that explain the pitfalls of such a goal, and how to overcome them.

This is a must for anybody that wants to understand rendering at a lower level.

VMath is a powerful NxM matrix template class which includes full support for matrices, vectors, points, homogenous transforms and more.

I use this in nearly every one of my 3D projects, and it's currently in use in a number of commercial games. It's proven, it's solid, it works.

MMGR is an industrial-strength memory manager for almost any project.

Not only will MMGR probably point out some bugs you never knew you had, but it is also a great development tool. Among other standard tracking tools (overruns/underruns, deallocation mismatches, etc.), MMGR also provides a rich featureset of developer tools. For example, it allows you to set a breakpoint on an arbitrary allocation, generate a snapshot report of memory currently in use, etc. You can even ask MMGR to track how much of your allocated RAM is actually in use (nothing worse than allocating 64MB of memory just to find that you only needed 2K. :)

FontGen is a font generation tool (from TrueType fonts) for applications that must render their own fonts (includes full source).

FontGen creates fonts that include the antialiasing information, so that 3D/2D graphics applications can render beautiful characters to the screen.

FSColor is a Color Picker tool for Windows that you can use in your own tools (it's a DLL.) There is also a pre-built executable if you just want to use it as a stand-alone tool. Of all the tools I've written over the years, this tool is the one I still use today and I use it all the time. It was updated for 64-bit processors in Jan 2014.

Adobe's PhotoShop product really nailed the color selection process on the head. I personally saw no need to improve on that, but I wanted a stand-alone tool that encompassed a few extra features (such as picking colors from the desktop & other windows, copying various color RGB formats to the clipboard, etc.) FSColor includes these features and more.

FSZoom allows you to magnify regions of your screen.

Once in a while, you need to work with pixels (especially if you do a lot of graphics programming.) This is one of those tools I use on a regular basis because it allows you to set up a zoom region, and as you work, the zoom auto-updates, showing you a live zoom view.

There are probably other zoom-in utilities out there like this, but this one is free. :)

FSRaid was once the #1 PAR tool on the net. It only supported the original PAR specification which has been superceeded by the PAR2 specification. You should track down one of the PAR2 tools instead of using this.

This software is no longer available.

These are the documents that originally started as the answer to a question on flipCode. I've since turned them into stand-alone documents. These may not be fresh off the copier, but they're still contain valuable information for anybody starting off in global illumination.

Here is an excerpt:

"I've found many people shy away from radiosity simply because of the mystique surrounding it. I'll admit that I was a bit intimidated by the topic when I decided to tackle it. But the truth be known, it boils down to some pretty simple techniques, most of which are very common. As a matter of fact, if you've got access to a rendering architecture that supports z-buffering, you've got 90% of a basic radiosity processor that can produce some excellent results."

Download:

Radiosity In English
Radiosity In English II: Form Factor Calculation

When building a BSP tree, it is most often necessary to find a reasonable balance between "fewest splits" (i.e. smallest tree) and "least depth" (i.e. best balance of nodes.) In most applications fewest splits tend to be more important, unfortunately, this is a most time consuming task.

Many applications that require BSP trees use a heuristic to determine a balance between "fewest splits" and "least depth". It is in this balance, that we find hope for an efficient solution.

It can be said, that because we're searching for a balance between depth and splits, there are a certain number of potential polygons (acting as splitters) that will result in the deepest tree, and should not be considered, even if they result in nearly no splits.

Given these criteria, we can find a range of the top contenders for least depth, and from them find the contender that results in the fewest splits. As long as we have enough "least depth" polygons to choose from, we'll find our target balance.

By doing this, we avoid the computationally expensive (and exhaustive) search for the fewest splits, and focus our energy on the least depth. From this reduced set, we find fewest splits, reducing our computation time.

Continue reading by downloading this document.

Note: The document's preface states that this idea is in concept stages. This was because, at the time, I hadn't implemented it in production code. Since the writing of this document, I've used this technique a few times and it has proven quite powerful for fast BSP-tree generation.