Last week I was working on a port of a Quake model viewer I did in OpenGL to ActionScript 3.0 and Papervision3D. The actual AS3 code is reading the Quake model information from the original binary Quake .mdl file and contains, besides the polygon data, the bitmap that represents the texture for the model. The problem is that Quake uses a global color palette because the game was programmed for 256 colors (remember, this game is from 1996!). None of the models or textures actually stores a palette because they are assumed to all use the same palette and why store it many times… The actual color palette is stored in a separate binary file of 768 bytes in size (256 * 3 = 768, the 3 is for the three r, g, b color channels and every component ranges from the standard 0 – 255).

When building the AS3 version of the Quake model viewer I could have chosen to read the color palette from the binary file by loading it in at runtime. Instead I chose another approach. I created a class that represented the color palette and I embedded the raw palette information as a resource in the swf itself:

package
{
   import flash.utils.ByteArray;

   public class QuakePalette
   {
      [Embed(source="quake.pal", mimeType="application/octet-stream")]
      private static const Palette : Class;

      public var r : Array = null;
      public var g : Array = null;
      public var b : Array = null;

      public function QuakePalette()
      {
         var i : int;
         var a : ByteArray;

         a = new Palette() as ByteArray;

         r = new Array();
         g = new Array();
         b = new Array();

         for( i = 0; i < 256; i++)
         {
            r[i] = a.readUnsignedByte();
            g[i] = a.readUnsignedByte();
            b[i] = a.readUnsignedByte();
         }
      }
   }
}

Above is the code for the actual QuakePalette class that is used by the AS3 Quake model viewer. As you can see, the color palette is embedded inside the class as a resource. By setting the mimeType property to "application/octet-stream" the data is actually embedded as raw binary data. In the constructor the Palette class (the alias by which the raw binary data is known inside the class) is then casted as a ByteArray to be able to access the data. In the end the QuakePalette class has three public properties, r, g & b, that represent the three RGB color channels for easy access.

Some months ago I was working on a conversion of an OpenGL Quake 1 model viewer I did years ago, it must have been 2000 or 2001 or something, to Papervision3D. The overall conversion went pretty smooth because all of the difficult stuff I already did when I was building the OpenGL version and the code was documented pretty well.

When doing the conversion there was one problem I had at the time and that was the texturing. I just couldn’t get the texturing to work correctly with Papervision3D. I read the Papervision3D documentation and searched the web from top to bottom and inside out to find an example of the correct way to apply a texture to a Face3D object. At one point I just gave up and the code started to collect dust on my hard drive.

Until today. For a commercial project I’m currently working on I’m going to use Papervision3D and since I could spend paid hours on figuring out what the problem was with this code it seemed the right opportunity to dust off the Quake 1 model viewer code and fix this issue once and for all. And behold, after a day of debugging and bending my brain over and backwards, I seemed to have fixed the problem.

Basically, and I will not bore you with the details, I figured out that the Papervision3D documentation wasn’t that clear since the Face3D class constructor didn’t expected an array of {x,y} objects for the UV coordinates but an array of NumberUV objects. Second, the UV coordinates had to be given in percentage, something I lucky remembered from my OpenGL programming days.

So, there you go. You can checkout the Quake 1 model viewer here (might take a couple of seconds to load) and please let me know what you think…