Curvy Component Connections

Above is a representation of the component graph used to generate the procedural texture in the previous blog entry (click image for full size version). The components are created with the NetBeans Visual Library, which seems very well suited for component based graphs.

I implemented a custom Bezier spline based connection path. I feel that it is easier to read and understand than one with straight lines, or non-overlapping connectors automatically routed in a manhattan grid (axis aligned, only right angles). The curvature of the connection adds some extra information; it is easier to see if a connection is going backwards or forwards, or spanning a long distance or a short one.

Researching splines took a surprising amount of time again, there was no simple cut-and-paste Java code available either. I found the Unraveling Beizer Splines article on informative and simple (despite some typos in the code), the Wikipedia article on Bezier curves has nice animated graphs, but was a bit too theoretical to base a quick implementation on.

The resulting Java spline code is available, if you want to use it.

On The Fly Compiled Procedural Textures


The procedural textures from the last time now have source code generated and stitched together for each component, and compiled on the fly using Janino. A trippy example texture can be seen above, created using four sin components, connected to inputs that change over the texture area, and outputs for producing red, green, and blue color channels.

The rendering time seems to be around 1 second (compared to about 5 seconds with a non-compiled implementation). I suspect the difference will be more marked with more complicated textures, as there is some overhead when the data is copied to a BufferedImage for rendering.

I ended up having to implement a Topological Sort algorithm for the dependency ordering, and a Cycle Detection algorithm to prevent creation of cyclical dependencies between components (I implemented that after spending about six hours trying to figure out what was wrong with the other algorithms, when there was a simple typo in the example code, causing a cyclical dependency). This paper on various graph algorithms was an useful reference.

Implementing the graph algorithms wasn't that straightforward, so I was considering using some existing graph library instead, especially as the next step will be to visualize the component graphs and edit them in a UI. However, it seems there are not many library aimed for graphs of components that can be connected to each other through input and output ports except for JGraph, which is a bit daunting in its complexity. A promising alternaive seems to be the NetBeans Visual Libray, which is aimed at graph visualization and graph oriented modeling. It would seem to be a perfect fit, provided it doesn't depend on all of NetBenas (doesn't seem to), and has a flexible enough model, and customizable visualization.

Playing With Procedural Textures and Code Generation


I'm working at a procedural texture system for Skycastle at the moment. The intent is partly to get a useful and fun texturing tool to play with, and partly to create a spike for exploring what a more generic component oriented procedural content editor should be like.

Based on some initial tests that just calculated random pixel values, it soon became evident that having components calculate the values and request calculated values from other components would be quite slow, so I decided to explore on-the-fly code generation. Janino seems to be one of the established libraries in this area. Janino has the advantage of not needing the Java compiler (which is only available in the JDK, not the JRE), instead it actually implements a large subset of a Java compiler.

Currently I'm doing some prototyping on what generated code would look like (by just writing it out by hand). An interesting looking result obtained with four sin functions and some constant parameters for them is shown in the screenshot. It is still slow (about 5 seconds for a medium size window on my T60 laptop), so I was thinking of including the whole pixel iteration loop in the generated code, to eliminate any method calls for each pixel.

Skycastle on Launchpad

I came across Launchpad recently. It seems to be a kind of common bug tracking and release management tool for open source projects, initially created for the needs of Ubuntu, but opened up so that any project can use it.

It's geared slightly towards larger projects, but it does provide a working looking bug tracking and release planning tool, so I decided to use it for Skycastle.

Vector graphics figure for isometric game


Here's the result of some experimentation with using vector graphics for rendering player figures.

It composes the figure from 'bone' shapes that are basically a line with rounded ends, where each end may have a different thickness. It also has a cell shading like shadow on one side, and antialiased highlight and shadow outlines (this helps to hide the otherwise quite jagged polygon outlines). The cell shading is just going down the middle of the bone currently, it will probably look better once it is bent a bit to either side.

I'm planning to divide the arms and legs still so that the figure has elbow and knee joints, and add hands and feet (I already did a test of a rotating arm with a hand earlier, and it looked nice).

For the head, I was thinking of drawing eyes, eyebrows, and mouth on it with simple antialiased lines. The hair could probably be approximated with a few polygons.

On the skirt front and back a custom bitmap image will be pasted, using a skewed bitmap renderer similar to what is used for walls.

So far I'm pretty happy with the result, with a bit of tweaking it should be a passable cartoon like figure. The next step is to figure out how to animate it..

Isometric Fun


I started working on an isometric game engine over this weekend, this time written in Python. I was inspired by the One Laptop Per Child project, and was thinking that some of my world editing ideas go well with their constructionist learning philosophy.

The end user experience could be something akin to building and playing with Legos together with friends, although the building blocks should be larger and more functional. No built-in game goals, but players might be able to define ones themselves. Maybe there could be some kind of toggle to switch between Build and Play modes.

The limited memory footprint of the OLPC laptop (no hard drive, only a few hundred MB of flash memory) imposes restrictions on the amount of media and map data that can be stored in a conventional way, so I'm also planning to experiment with procedurally created maps and graphics (the map above is defined with one ProbabilityMapFill, that selects between normal and flowering grass tiles, one WalledMapFill, that builds walls around a specified area, and a SolidMapFill, that fills the same area with an earth tile).

The mesh-networked nature of the One Laptop Per Child machine also means that this would be a peer-to-peer game, not a conventional client-server setup. Anyone could start or resume a game session, and invite others. Constructs and pieces of landscape created in a session should be possible to keep for later, and to share with others.

I'm not sure yet how side-tracked I'm going to allow myself to get with this project, but so far Python is relatively nice to code with, despite a few oddities and the lack of an IDE with rename and code navigation features.

Setting Up Skycastle Project Infrastructure, Take Two

Update: I recently moved the Skycastle website hosting to, as sourceforge was slow and a bit unpractical to use for a mediawiki.

In my first blog entry from end of 2005 I was looking for a hosting and wiki solution for the Skycastle project. I've settled for using SourceForge for hosting, after they started to support SVN.

However, I hadn't really set up any satisfactory wiki for the project. I've been using Mediawiki a bit over at the WorldForge wiki, and really like it's advanced features.

I finally spent last Sunday setting it up on Sourceforge - it is actually possible, although it requires some work (like writing a database driven mail sending script, as direct mailing from web applications on SourceForge is not allowed - I still have to do that).

There are various instructions on the net for how to set it up, although they are not very clear or complete in all cases (on Mediawiki help pages, on László Monda's page).

As an aside, SourceForge also seems to offer a wiki solution now, but it didn't look too impressive - it seems to lack categories, templates, and a lot of other useful things found in Mediawiki. Running Mediawiki also allows me to tune its appearance so that it can be used as a respectable homepage for the project.

Google Summer Of Code - 3D Rendering Pipeline for Geotools

I'm participating in the Google Summer of code program this summer, working on a 3D renderer for Geotools.

This will be a good opportunity to get familiar with the Geotools library - it might be usable for storing geographical data in Skycastle. I'll also try to make the 3D rendering pipeline usable for real time low altitude rendering with relatively high detail - usable for games, as well as various interactive geographical visualization applications.

Real time generation and rendering of realistic landscapes

A Dutch landscape painting from 1820 (by Adrianus van der Koogh). A challenging goal to aim for in landscape generation and rendering.

I haven't used this blog much yet, but I was thinking of starting to blog regularly now. So to clear up the backlog, here's my masters thesis on landscape generation and rendering, finished in the autumn 2006.

In it I review a number of algorithms for generating and rendering various aspects of landscapes, from terrain to plants, buildings, and the sky. I also discuss a bit how to use ecotopes to distribute the landscape features naturally.

I tried to illustrate it throughly and make it easy to read, so feel free to check it out. Apart from some of my not-so-interesting building generation experiments in the middle it's mostly a review of existing approaches with a few ideas and improvements of mine thrown in. It can serve as a kind of pre-study for a landscape engine.

Here's the abstract:
With the increasing size of virtual landscapes in games and other applications there is a growing need for generation algorithms that can help designers to produce large realistic landscapes. Parametrized procedural and fractal systems provide this, and also enable on-the fly data generation that minimizes required storage space. Ecotopes provide a way to introduce natural variation in automatically generated landscapes by varying the generation parameters based on the location. Interactive performance can be achieved by using geometry with a level of detail that decreases with the distance to the observer. In this thesis I evaluate different algorithms for generating and rendering terrain, vegetation, buildings, cities, and the sky. New algorithms are sketched out for terrain generation through successive uneven mass deposit, elevation map modifying textures, river system generation, pattern based city generation, and weather modeling. A subdivision based house generation algorithm is also presented and partially implemented. Finally opportunities for further research in conveying emotions with landscapes are identified.