WDQuick Links: Tank Software, Tank Ammo ForumsSite Map
William Denniss
Tank Image Current Projects
PSP Title
I am currently working on a commercial PSP title, details of which will be available on release.
Tank Image Finished Projects
Developed in 2005 with Philip Worthington, "Projected Lineriders cars follow lines that people draw on the surface with pens, speeding up and slowing down according to a visual annotation language. The cars skid and crash and jump over obstacles like hands, bridging the space between the physical and virtual. The game is open ended, nurturing peoples' own creativity and imagination as they strive to create the perfect track."
A high performance accellerated 3D graphics rendering engine and scenegraph with some compatible functionality to the old Java3D scenegraph. I was previously an active member of the Xith3D development team.
Odejava is an API which allows Java developers to use the uses the ODE physics engine with their Java projects and in an Object Orientated fashion. It is capable of working closely with Xith3D. I was previously an active member of the Odejava development team.
Digital picture manager for use with digital cameras and online photo galleries.
Internet password and username remembering program.

opengl Y Is Up?10 May 2004

Computer programs typically use a Cartesian 3D Coordinate Space to represent virtual 3D worlds. Unlike our world were the up direction is simply the opposite direction of gravity, the 3D coordinate space has no such notion. Thus, when createing a 3D world, one of the three axes is picked to represent the hight (i.e. the up direction).

Logically, I believe Z should be up, If you are looking at the world, the X,Y coordinates specify where you are on the map, and Z is your height. However, the industry standard is that Y is up. The reason being that it takes the view not of the 3D world, but of your computer screen where, like with 2D graphics X and Y are the screen coordinates and Z is the depth (away from the screen).

It's quite possible to use Z as up in a 3D world, however it may be more trouble than it's worth. Why? Well the underlying graphics API most likely uses Y is up. Easily avoided - simply reverse the Y/Z parameters to all API calls. But the problem is that most modelling programs have the same view - so most 3D models will assume Y is up. So they must be rotated (either at design time, or in the code). Then if there are moving parts, more considerations must be made, especially if you are unable to rotate the model coordinates (and have to transform it in the code). So in the end, instead of making it easier to imagine the scene (by using the more ``logical'' Z is up) it ends up being an obfuscated mess both to view conceptually, to code and review.

As I have discovered, it is much easier simply to use Y is up, like everyone else - and just ``transpose'' your thoughts to switch the two rather than trying to switch them in the code.

For the unconvinced, the following picture should be the final nail in the coffin for any 'Z is up' plans.

The Simpsons - Treehouse of Horror VI


Return to the Main Page