Here's some more of my long ramblings about what's going on. I formulated the TBN basis vectors as a linear system of equations. I still think there's a better way of doing this, though, since the TBN matrix always has to use the face normals now. This means I can't use the precomputed normals provided by the artist (well, generated by the 3D modelling app). As a result, I switched to using the weighted averages method for calculating the vertex normals in order to eliminate the blatant blockiness of the models, but this limits the artist's freedom to modify the smoothness of each surface. At least all of this work will allow me to have animated 3D models with normal mapping in my engine. Here's a lovely picture of the new-fangled tangent space coordinate system vectors:

Tangent Space Vectors

I really need to try to optimize this stuff, too. I'm doing a ton of matrix math every frame because of the interpolation required by the keyframe animation code. I'm almost certain some of the repetitive number crunching can either be done lazily or precomputed. Maybe I should look into skeletal animation while I'm at it (in other words, derive a Quake 3 or Doom 3 model loader from my object base class). Come to think of it, the shadow code is doing a lot of repeated work, too... I still want to stick to my goal of having the final product run on a Geforce 6 or better.

In other news, I quickly hacked together some parallax mapping in a pixel shader. It's pretty simple stuff once you realize that all you really need to do is distort the texture coordinates of the normal and the texture maps based on the view vector and the height of the surface. This is about as exciting as a 10 polygon room gets unless I venture into the realm of relief mapping shaders.

Parallax Mapping

Another shot of parallax mapping

I have a lot of boring infrastructure stuff to throw in now since there's no real scene graph yet. I'm embarrassed to say this, but I still need to coalesce all of my shadow rendering into one pass. On the plus side, having a scene graph will allow me to optimize things, clean up a lot of code, add in camera support (complete with my quaternion class), and load up some interesting scenery (read: Quake 1,2,3 levels). I will finally be able to integrate my HDR lighting code from my other project into the engine, too, so things will start looking as good as Oblivion (wishful thinking). Actual gameplay is still a long way off, but I haven't decided yet whether to work on some of the game logic before or after the scene graph. And finally, an obligatory mock gameplay screenshot:

Gameplay "concept" screenshot

I added in the bump mapping code from the teapot demo. I made a point of using that cliche brick texture that every bump mapping demo on the planet uses. I still need to decide on how I'm going to precompute the tangent vectors for every surface on the Quake 2 models though. That will give me a chance to do away with the Quake 2 normal lookup table. Here's what I've got so far:

Bump Mapping

Parallax mapping, relief mapping, and HDR lighting are on their way.

I finally snuck in some more coding time. I got around to writing a Quake 2 MD2 loader for my 3D engine, and I reorganized a lot of the code. I also implemented stencil shadows complete with self-shadowing! Eventually, I could do psuedo-soft shadows by jittering the light and rendering a bunch of extra passes, but right now, the hard shadows look fine. Quake 2 models have extremely low polygon counts, of course, and the normal vectors are pulled out of a single lookup table that every Quake 2 model in the world uses (yikes). Maybe I'll have to try computing weighted average vertex normals instead because there's visible discontinuities along the surfaces.

Quake 2 Player Model

What's left? More model formats, multiple lights, multiple shadow casters, more code reorganization, and tangent space vector calculation for the normal maps. I've been struggling to get a water shader going with normal mapping and environment mapping because of tangent space coordinate system issues. I will probably revisit the problem sometime later on. I have a few workaround ideas. Lastly, the environment needs to be more interesting than a brick box. I'll be looking into loading vintage Quake maps and rendering them using normal mapping and stencil shadows like Tenebrae does. Basically, Doom 3 graphics with decade-old artwork. You probably noticed that there isn't any HDR lighting in this screenshot. I'm still cleaning up the code for that. My rigid body dynamics engine is temporarily in hiatus until I replace the hackish impulse-based contact forces with an analytical LCP solver.

Quake 2 Weapon

I've been slowly but surely working on a rewrite of the OO3D engine. I've removed the ODE support, and I have integrated my rigid body dynamics engine from the flight simulation. Also, I've started reading papers about some of the more recent graphics technologies and have incorporated them in my engine. A lot of new features have been added, especially with GPU programming. I'm still sticking with OpenGL for now because it's multiplatform.

Teapot Picture

Here is the venerable Utah Teapot rendered using HDR lighting, cubic environment mapping, refraction, reflection, chromatic aberration, bump mapping, parallax mapping, and per-pixel lighting. The HDR lighting uses floating point FBOs, performs luminance tone mapping, and loads HDR light probes in the OpenEXR/RADIANCE format. Right now I'm using the common "Campus at Sunset" light probe along with an inflated exposure time setting in order to exaggerate the Gaussian bloom effect. For the sake of the tech demo, I threw in every single feature I could. It gets about 30-40 FPS on my Geforce 7950 GT. I haven't really optimized anything yet, and there's still some very prominent aliasing around the edges. There's no shadows yet because I haven't decided whether I want to go with stencil shadows, shadow mapping, or some sort of soft shadowing. I also need to work on loading 3D models and displaying environments such as terrain or BSPs. The mathematics behind realistic water rendering seem fascinating as well, and I can't help but look at Crysis and wonder how it works. Hopefully, I'll be up to speed with some of the newest rendering technologies soon.

Everyone deserves the opportunity to receive a first-rate education and to freely pursue their own intellectual interests. With respect to this ideal, the One Laptop Per Child project sets its sights on providing $100 Linux-based notebook computers to children in third world countries. The project emphasizes affordability by using economical hardware and software components. It also promotes connectivity via mesh networking.

I was lucky enough to have been provided with a computer and Internet access when I was a child, and it pretty much changed my life. I suppose my Nintendo DS work can be compared to this project because I envisioned transforming the device into a functional $200 computer with wireless Internet access. Spread the word; this is a good cause, and computers could have the same effect on others' lives as they did on mine.

Be sure to share your support for Wintermute and his library that makes NDS homebrew possible. Nominate Devkit Pro for the Sourceforge Community Choice Awards. Everyone seems to be picking "Best Tool or Utility for Developers" for the category:

In other news, I posted a new happy hardcore mix of Rank 1 - Airwave here. I've been working on it off and on for a few weeks with my M-Audio Axiom keyboard.

Also, I've been experimenting with web-based 3D graphics using Java. If you have the latest JRE, check out my demo. It might take a while to load because I'm hosting the JOGL and Gluegen library files on my broadband line at home. I have some pretty big plans for online Java applications. In the meanwhile, convince Sun to release a 64-bit browser plug-in!

EDIT: I better move the Java rant to another section. :P

All right, here's a much-needed StellaDS Atari 2600 emulator update before the major overhaul begins. Changes include:

• DLDI and libfat support for all of the new flash cartridges
• Updated to latest Devkit Pro tool chain
• Long-awaited streaming sound without any crackling and popping noises
• Code optimizations (code in the ITCM and the new armv5te compiler optimizations)
• Faster speed but still not 100%
• Usability enhancements with the menus (key repeat, no more bogus dot entries)

So now the sound finally works as it should, and many more people with micro SD cards and the like can enjoy StellaDS. Look forward for more features in the future! Wifi multi-player Warlords or Pong anyone? How about 100% speed via an assembly-optimized CPU emulator? I can't make any guarantees, but I'm definitely trying to implement these features. Grab the new release from the StellaDS Download page. Enjoy!