OpenTTD 32bpp Part 4 - The Finished Product

By using 3D graphics and automation I was able to make a complete complete, high resolution, graphics replacement for OpenTTD almost completely on my own...

Making this graphics set was still a hell of a job though:

The total time I spent in Blender to make the graphics was 135 hours to make 391 blender files.
To render all these Blender files into sprites took 14.16 processor hours to produce 69931 images.
The final downloadable graphics files are 273 Mb and have been downloaded 24123 times.
The total size of all 146280 source files is 2349 Mb.

You can find out more about OpenTTD at http://www.openttd.org/ and more about this high resolution base graphics set (called zBase) here and here.

Software used:

Blender: 3D modelling and rendering.
ImageJ: Sprite post-processing and managing.
Python: Computer usage tracking.

OpenTTD: The game!

OpenTTD 32bpp Part 3 - Automation

3D software makes it quick and easy to make high quality textured and shaded sprites, but it is not just limited to still images; 3D software is normally designed for animation. Using the animation tools in Blender I could massively simplify producing sprites for OpenTTD.

The graphics for different trucks are a great example.

There are 3 different generations of truck graphics (old, current and futuristic), 16 different cargo types and loaded and unloaded graphics; that's 96 different combinations! Designing the graphics in 3D allows the truck to be broken into chunks; the truck body, the trailer and the cargo.

A screenshot of the 3D source for the truck graphics.

With this setup making the various combinations of truck body and cargo is simple; different animation frames just have different trucks and cargoes positioned in front of the camera. It does need a bit of geometry to get all the angles perfect though:

OpenTTD's sprites have the front left and front right sides at 26.56805 degrees from horizontal.

In 3D it is simpler, the camera is at an elevation of 30 degrees.

Each truck has 8 sprites for the 8 different directions it can drive in. Creating these 8 different images using the animation tools in 3D software is also easy, just rotate the truck 360 degrees in front of the camera over 8 frames.

Finally a few extra images are needed to complete the set of sprites required. One of these is the mask sprite to show which bits of the truck should be coloured using the company colour:

Other ones are the different sprite sizes for different zoom levels (256px, 128px and 64px).

Handily these types of outputs are also useful for animators. This tangle of image processing nodes in blender automatically generates and saves these different images:

This level of automation generates all the sprites OpenTTD needs with the minimum of effort. With a little bit of coding these sprites are now recognised by OpenTTD and can be used.

Continued here: OpenTTD 32bpp Part 4 - The Finished Product

Software used:

Blender: 3D modelling and rendering.

OpenTTD: The game!

OpenTTD 32bpp Part 2 - Moving to 3D

The original OpenTTD graphics were 8-bit. This means that all the images were made up only of colours taken from a palette of 256 different colours. This image:

Is only made up from colours from this palette:

 For example you can take all the pixels from the building which are the grey shade indicated in the palette:

An 8-bit image format was used because it was much faster for older computers to display. While the images are simpler it actually makes the graphics harder to draw for a person; every single pixel has to be picked carefully. It isn't possible to use normal photoshop techniques like altering brightness or contrast or reshading the graphics which makes things difficult. Imagine having carefully drawn a brick wall. To use it on the shadowed side of the building you are forced to completely redraw it.

In contrast 32bpp images are easy to make, especially using 3D modeling and rendering. The fact that OpenTTD can now use 32bpp graphics is therefore a big advantage! Once a building is designed in 3D (modelled) the rendering process (converting it into an image) calculates all lighting, shadows, shading etc. This makes it very quick to generate a realistic looking building because the computer does a lot of the work for you.

 

The building as modelled in Blender, the lamps for lighting are the dotted sun-shaped objects on the right.

The rendered image with accurate shadows and shading.

In the same way that 3D modelling and rendering make lighting and shading simple they also make texturing simple.

In the old 8-bit graphics textures like brick walls had to be hand-drawn, brick by brick. With some smart texture design and 3D rendering even hard-to-draw materials can be rendered quickly and accurately. Like with lighting and shading this is far quicker than drawing the texture by hand.

Brick texture on some simple objects

Brick texture on a really complicated object!

With lighting, shading, and texturing simplified by 3D modelling and rendering this actually makes the new, high resolution graphics easier and quicker to make than the old ones. The modelling is still a bit tedious though...

Continued here: OpenTTD 32bpp Part 3 - Automation

Software used:

Blender: 3D modelling and rendering.

OpenTTD: The game!

OpenTTD 32bpp Part 1 - Making a Massive Graphics Update

If you didn't know OpenTTD is an open source remake of the classic "Transport Tycoon Deluxe" by Chris Sawer, the maker of Rollercoaster Tycoon. It still has a huge cult following! Unfortunately the original Transport Tycoon graphics, which can be used in OpenTTD, look slightly dated (1994/5)...

 The original graphics

Originally OpenTTD relied on the graphics from the original game. In an effort to make the game fully free to play the graphics were redrawn from scratch, a massive project that took nearly 3 years to finish. Unfortunately these were subject to the same technical limitations as the original Transport Tycoon graphics:

 The free graphics replacement

The biggest problem with these graphics is their size. The game was originally designed to be played on a screen only 640x480 pixels in size. Modern screens (like an HD display) are nearly 3 times wider/taller with 9 times the area. In an effort to make the game more playable extra zoom levels were added: now the view can be zoomed in 4x further, but the result is not pretty:

 I can see pixels!

The solution? Redraw all the graphics. Again. The result is totally worth it though:

One retina display-safe set of graphics.

OpenTTD uses a (now quite outdated) method for displaying game graphics in which every in-game object is a single image called a sprite, like this:

 

One construction stage of one building.

In some ways this makes a complete, high resolution, graphics replacement is simple; all you have to do is draw the big brother of each sprite:

The same sprite, 4 times larger and with better colour depth and full transparency.

While this this sounds simple it is still a mammoth task. There are currently 11949 sprites (11949 separate images) required for OpenTTD. These cover all the objects, buildings, vehicles, industries, etc. to cover all the four different world environments you can play in... Some of these don't need to be replaced (like the sprites used for the fonts) but it is still a huge number of images.

So could I possibly go about doing this? In short, automation and 3D rendering.

Continued here: OpenTTD 32bpp Part 2 - Moving to 3D

Software featured:

OpenTTD: The game!

Cell Picture Show

One of my scanning electron microscope images from my research into the division of Leishmania parasites is currently featured in the Cell journal picture show on parasites and vectors. You can check it out (image number 11) here.

A montage of seven scanning electron micrographs of L. mexicana.

"Leishmania mexicana promastigotes, which normally inhabit the gut of the sand fly vector, are shown at different stages of the cell cycle. Cells are arranged by cell-cycle progression, increasing in a clockwise direction. L. mexicana mainly causes a mild form of cutaneous leishmaniasis, forming ulcers at the bite site of an infected sand fly."

Software used:

ImageJ: Micrograph processing

Flippy Clocks

I have always loved the classic flip clock style, and it makes an interesting test for my HTML5/canvas programming skills. This little clock project uses no images, instead it uses 60 hidden canvases to draw the top and bottom halves of the flip cards. These are then assembled into the final clock which appears live on screen.

Try it live here.

Live Earthquake Monitor - WebGL

Earthquakes, while devastating, are an amazing natural phenomenon. When, where and how deep under the Earth's surface tell us a huge amount about the way the Earth works...

About 18 months ago I made an interactive, live and very informative website mapping recent earthquakes:

View it live here.

This was my first ever interactive website of this type of complexity and I am still very proud of the result! Still, styles change, my programming ability improves and, most importantly, new technology becomes available. This is the all-new updated result:

View it live here.

This new version makes use of WebGL which is a new way of displaying 3D graphics in your browser. This technology is not available in all web browsers yet (it is available in recent versions of Firefox and Chrome) but allows fast, smooth, full 3D graphics. In short it looks beautiful, try it out!

Software used:
Three.js: Excellent javascript library to simplify using WebGL.