Fast forward many hours of coding and here is a simple demo (click the image to launch it):

The demo consists of 3 separate scenes. You can switch between by simply clicking in the window. Further mouse and keyboard controls are listed in the demo window itself. Debug output from the demo is viewable in the Java applet console

Architecture

I’ve tried to use good object-oriented programming as much as possible throughout. For example, each scene is represented as a hierarchical scenegraph and a Visitor model to perform rendering. The renderer itself is obtained from a Factory which allows for different types of renderers (OpenGL, DirectX, Software, etc.). As is standard practice with scenegraphs, a matrix stack is used to allow for model-level transformations independent to world-level transformations.

At the moment the only available renderer is software-based. But the architecture allows for OpenGL or DirectX-based rendering to be added in future. I use the Graphics2D.drawLine() API call in Java to render the pixels. Everything else (e.g. z-buffer) is manually implemented. The engine supports wireframe-mode rendering and backface culling. There is a single source light in the scene whose direction can be modified (in the demo it’s always pointing forwards from the camera). The rasterizer currently uses flat shading – next would be to add Gouraud and Phong, not to mention texturing.

3D rotation on world objects are performed using matrix multiplication. The camera is rotated using Quaternions since this made it simpler to use the UVN camera model. The third scene in the demo above is animated; this is accomplished using a simple timer thread using which any number of events can be scheduled for execution at given time intervals.

Performance

When programming in Java it’s easy to not worry about memory usage and allocations since the garbage collector handles the freeing up of memory. But for graphics engines every allocation or garbage collection run will impact performance. So from the outset I’ve tried to pre-allocate memory where possible, by constructing temporary vectors and matrices for use during calculations later on. Thus, the vast majority of the matrix and vector multiplication which take place in the render loop don’t allocate any new memory when doing so.

However, when I finally started rendering things I found that the performance bottleneck was actually the rasterizer. The more polygons (triangles) that needed to be drawn and the larger they appeared on screen, the longer each frame took to render. Perhaps I can improve this by optimising the polygon order (e.g. render from farthest to nearest) and improving the raster algorithms. Eventually I want to switch to using OpenGL as the rendering system but since I’ve come so far with the software renderer it would be nice to see if I can improve it a bit more first.

Download

The engine code is licensed under the LGPL and is available here.

• Hierarchical scenegraph including Mesh, Rotation, Translation and Light nodes.
• Triangle primitives with helpers for building cubes
• UVN camera with orthographic or perspective projection
• Timer scheduler for animating the scene.
• Rendering system abstraction
  • Renderers follow Visitor design pattern
• Software-based renderer
  • Wireframe/flat shading
  • Simple directional light
  • Backface culling
  • Pixel-level z-buffer
• Customizable interaction (i.e. user input) handlers

More information can be found in the original blog posting.

Demo

Launch demo (requires Java 1.5+)

Download

The source code for this engine is licensed under the LGPL 3.

Download source code.

Build instructions can be found in README.txt in the download package.

Also, I’ve put up a few Java classes I wrote a while back as a small library called Common-Utils. Included within are the following:

• ArrayUtils – Utility methods to fill an array with a given value or check if it contains a given value.
• DynamicArray – A resizable “static” array for when you don’t quite need the full flexibility of ArrayList.
• NonMutableIterator – Wraps around a normal Iterator and disables use of the remove method.

• ArrayUtils – Utility methods to fill an array with a given value or check if it contains a given value.
• NonMutableIterator – Wraps around a normal Iterator and disables use of the remove method.
• JAbstractApplet and JAppletSimulator – Classes for running applets as standalone applications.

License: LGPL 3.

Current version: 0.1

Download

Download source code and documentation.

Changelog

• 0.1 (Jan 15, 2010)
  • Initial release.

After leaving Symbian I went to work a mobile software startup whose primary concern was a mobile social networking app written in Java MIDP. Now, if you want to stay as true as you can to the “write once, run anywhere” principle for mobiles then Java is really the only choice since almost every phone out there has some sort of Java support, albeit each with its own various inconsistencies and quirks. Writing a mobile Java app was also a whole lot easier than writing one in Symbian C++. The availability of great development tools (Eclipse, JUnit, ProGuard, etc.) didn’t hurt either! Having worked on a mobile Java client I decided that if I was to build my own mobile app I’d have to do it in Java.

Then iPhone came along and 2 years later it’s now obvious that if you have a good idea for a mobile app and don’t mind learning to develop on the Mac then you might as well as write your app for the iPhone, thus giving yourself a real chance to earn a decent income from it. Many of my fellow engineers have had iPhones for a while and some of them are even starting to write apps for it, some lured by the prospect of making a killing, others just wanting to do something cool for what is hailed as the “Jesus phone”.

My T-Mobile contract is about to expire and I started seriously thinking about whether to upgrade to an iPhone or an Android handset. After much deliberation, I bought myself a lovely little T-Mobile G2 Touch instead (also known as HTC Hero). It runs Android 1.5, the latest stable release of Google’s mobile OS. Android development is essentially done in Java (the bytecode format and VM varies) using APIs which are different to the MIDP ones. You can use Eclipse to code, test and debug your apps. It’s an open source OS, which means you’ll be able to find deployable versions of the OS on the web which even include features from the upcoming 2.0 release of Android (e.g. multi-touch) folded into the current stable release.

If you read around you’ll find that the Android Market and consequent ecosystem for paid apps is almost miniscule compared to the AppStore (see article and comments and follow-up), but I’m hoping that this will improve in the near future. And anyway, if the Android app platform doesn’t really take off then atleast I’ll already have some mobile app development experience by the time I get my iPhone

Update (Sep19): I’ve shifted the instructions for updating the HTC Hero/T-Mobile G2 Touch firmware into a new post