Donnie’s Blog

Lately I have been tinkering with a simple little 3D graphics program in my spare time. To support my various graphics and math projects I have put together a simple C++ math library including matrices, vectors, and the like. My matrices are stored in row-major order, like most matrices in C/C++ programs, but OpenGL uses column-major order. “Simple,” I think, “I just need to transpose my orientation matrices before passing them to OpenGL!”

But it just wouldn’t work. See if you can figure out why:

  template<class T, int dim> class SquareMatrix {
    ...
    /** Transpose the matrix. **/
    void transpose() {
      for (int r = 0; r < dim; r++) {
        for (int c = 0; c < dim; c++) {
          // Diagonal elements don't need transposing!
          if (r == c) continue;

          T tmp = getElem(r, c);
          setElem(r, c, getElem(c, r));
          setElem(c, r, tmp);
        }
      }
    }
    ...
  };

This is the first time that my computer has ever been too fast for me!

I needed to come up with a good programming problem that would be easily parallelizable. So, I fell back on the old standard, the Mandelbrot set. I got the single-threaded version working yesterday, and much to my dismay, it was really fast. What’s the point in parallelizing a fast program?

Nonetheless, I love the Mandelbrot set. Here are some pictures I generated:

Most of these images only took a few seconds to generate. Back in 1995 when I wrote my first Mandelbrot viewer in CS3, it took several minutes to generate images this large. The parallelized version would still take 30-45 seconds.

So, since this is no longer challenging enough for modern computers, I’ll have to find something else. Volumetric rendering sounds pretty good…

Yesterday my brand-new copy of LightWave 3D showed up! That was pretty neat. It was fun looking through the material that came with it, and recognizing scenes from Battlestar Galactica and a whole bunch of other TV shows and movies. This is cool. Initially I was thinking, “Why do I need this??” I really like Blender - it does what I need, and it’s free! But now that I see how much LightWave is used in the SFX industry, it’s getting pretty exciting to start learning it.

This is also the first software that I have ever owned that needed a dongle. Yet one more thing to worry about losing.

I went straight to the LightWave SDK documentation, since I want to learn how to drive LightWave with programs that I write. The API looks pretty good, and hopefully it won’t be too difficult to get a plugin working. My only concern is that I haven’t seen any documentation about computational geometry APIs, or collision detection APIs in the SDK. But that shouldn’t be a problem, since there are some pretty good open-source libraries available.

Don’t misunderstand - it’s still in beta right now - but I am still pretty excited about Java3D 1.4 being released soon. Version 1.4 of Java3D is focused on introducing one major feature: programmable shaders! And, given that I have just been learning about GPU programming, I think this is pretty awesome.

It looks like the Java3D 1.4 shader-support only allows “uniform” shader-variables; that means their values don’t change on a per-vertex (or per-pixel) basis. Rather, you set the variable before rendering a whole polygon or a group of polygons. I think this is a fine limitation; that is the most efficient approach to use, and it also matches up with how a low-level feature should be used from a language like Java.

Anyway, something new for me to download and play with…

I started learning the GPU shader programming language Cg yesterday. In fact, I reviewed a lot of things, including Microsoft’s HLSL and the OpenGL shader-language GLSL. But, since I can only learn so much, I decided to stick with Cg for now.

(more…)