Paul Nettle's personal website
Thanks for stopping by!
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:
$LASTname + "." + $FIRSTname + "@" + substr("sh8dg_GMAIL_sgsg", 6, 5) + ".com";
In the sections below, you'll find the more popular features along with a brief explanation.
Take what you want.
Share what you can.
- Paul Nettle
FSRad is a radiosity processor specialized for lightmap generation. Given a geometric database, FSRad will generate tightly packed lightmaps for your scene, remap the scene for these new lightmaps, slice polygons when necessary to allow them to stay within the lightmap resolution and illuminate the scene using a very precise radiostiy solution. In other words, it's a complete solution for high quality lightmap generation. The process is entirely automated, just click the big "Go" button.
Generic Collision Detection Using Ellipsoids
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.
These downloads are based on the document Generic Collision Detection for Games Using Ellipsoids. IMPORTANT: This document has been deprecated. It might be useful as a general guide, but please refer to the demonstration/source code (below) for implementation details.
Public source release of The Complete Morph
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.
Skeleton Graphics Application
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.
Accurate Software Rendering
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.
Matrix Template Class ("VMath")
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.
MMGR - The Memory Manager
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.
FontGen - Font generator
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. :)
Fluid Studios Color Picker (v2.6.1)
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.
Fluid Studios Desktop Zoom Utility
FSRaid 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.
FSRaid - Fluid Studios Software Raid Toolkit
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. :)
Radiosity In English (Parts I & II)
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.
Fast BSP-Tree Generation Using Binary Searches
FSRaidThese 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."
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.