Planet Generator

Sketches have a way of growing old when you don’t touch them for a couple weeks. Aug06 is a random planet generator that I worked on pretty furiously for about four days, and then promptly got bored of. It seems that the more you work on a project, the more you become interested in it, and also that the less you work on a project the less you become interested :P. Anyways, here’s a basic outline of what happened:

First draft. Map a 2D Perlin noise grid onto the sphere. I made a wrapping error by saying the elevation angle should wrap around from PI/2 -PI/2 (which is why all of the lines go towards the bottom center point).

Added plane-drawing and colors based on height. This image shows the major issue that this sketch faced: working in a spherical geometry space. The 2D Perlin noise field produces different heights for different multiples of two pi, thus creating that abrupt line. Also apparent is the squishing of the rectangular projection near the pole of the planet.

It’s an alien planet! LOL. My halfbaked puns will destroy you. This also shows that Perlin noise is an even function, hence unwanted symmetry.

After a rethinking of the underlying mechanism, the planet’s starting to look like an actual planet. The coloring is now a nice gradient; I superimposed several Perlin noises of different time/height scales for a more natural look. I got rid of the Perlin problems by a) adding an offset to the parameters so that there was no symmetry, and b) writing a “smooth” method that basically Gaussian blurs all of the heights. The basic outline for creating a planet is to generate a height map based of Perlin noises and then turn everything below a certain height into ocean, creating semi-realistic looking seas/lakes.

I actually wasn’t originally sure how this planet got to be so swirly, but it looks good. Also, it’s amazing what a simple call to lights() will do to a sketch.

The swirliness was caused by a bug in my smooth method, which actually turned out kinda nice. Definitely gives you pretty unique looking planets.

Replaced the Perlin noise with Simplex noise, which tends to be much more hilly and “regular”. This planet was such a fuck that I just had to include it :P

Floating green squash generator! I started adding terrain features such as hills and mountains, but got one of the coordinates wrong. Also added the starry background + sun which looks quite nice.

Added a coloring method that takes a look at the slopes of various places and tries to color them differently. My goal was to make cliffs look worn out and rocky instead of nice and green. It didn’t really work. I added huge crater features in combination with the Simplex noise and lots of small pokey mountains to get… some evil alien meteor. I really started to lose hope of this sketch ever looking the way I wanted it to.

Plateaus. Change. Everything. Early on I added the ability to render the map in a rectangular coordinates as to help debug various rendering bugs, but this image was particularly pleasing since it has many “nice” features – nice terrain and interplay between the land and the ocean (particularly with regards to those little pointy mountains), multiple levels of terrain with the plateaus, and good coloring (the cliffs actually look yellow, and the very top of the mountain is capped with snow).

Now THAT was what I was looking for. It definitely looks a little cartoony (actually it reminds me of the planets in Spore) but the features are there. I like the way the shoreline looks, especially with regards to that half-white half-blue tone near the center of the image implying a nice shallow pool area. The cliffs also stand out quite nicely.

I wondered what would happen if I took a bitmap image and made a heightmap and colormap out of the pixels. I took my desktop background, a screenshot of the gorgeous multiscale turing pattern, and mapped each pixel’s brightness into a corresponding height point on the planet and each pixel’s color into a color point (obviously). The result wasn’t as beautiful and awe-inspiring as I had hoped but I’m still quite pleased with it. You can make out the valleys and larger features.

Added primitive tree textures; also abstracted out the rendering to let any arbitrary coordinate system draw the heightmap (e.g. into torodial coordinates, as shown).

Change the color of “ocean” to transparent, to interesting effect.

See the sketch here.

I actually wrote a simple framework with which to easily populate the world with “things” – e.g. plants and animals, man-made features like towers or little villages, flocks of birds, giant turtles, clouds, floating land masses, moons, etc. Unfortunately I never got the time to actually IMPLEMENT all of those ideas. Perhaps I’ll come back to the code later on and give my planets some life.

One thing that really bothers me is that I never fixed the rectangular -> spherical projection problem. There is no perfect way to project a rectangle onto the surface of a sphere, which creates a bunch of issues. What I’d really like is some way to be able to tile the surface of the sphere regularly; perhaps with hexagons or triangles. But this is a whole other field that deserves its own sketch entirely…

Generative Terrain, Proscene, Algebra, Proguard

I love generative content. It would be my dream job to work on procedural generation for content in games. I feel that there is a lot of room for improvement in this field. The idea of generative maps has been around for some time and adds a level of replayability that I really love (think of how boring Nethack would be if every single runthrough had the same map).

I started off by sampling 2D Perlin noise at regular intervals and displaying it as a bunch of 3D rectangular prisms, which worked fine but wasn’t particularly interesting to look at. I added a color gradient from toxiclibs that would match different heights with different colors; the lower levels were made a deep blue to look like water, which then faded into a small of light yellow for sand, which then became green for a grassy look, etc. etc. Adding that really improved the aesthetic quality of the sketch, since I suddenly had hills and valleys and little ponds. In retrospect I probably should’ve taken screenshots of the sketch as it progressed; unfortunately none exist so just imagine it :P.

For a while I wanted to do a first-person (FP) camera where you could move around the terrain and look around you, so I used the Proscene library, since it is by far the best 3D camera library out there right now. I tend to have problems with conceptualizing cameras and 3D orientations; the vocabulary in particular throws me off. I had a mostly working FP camera by setting the Z position to be whatever the height of the block was, but kept running into weird problems related to the definitions of pitch, yaw, and roll and their relation to either the coordinate system that was set up or the “target” I was looking at. I would really appreciate if someone could enlighten me or point me to a nice tutorial on understanding such things, or possibly a library geared towards intuitive FP camera movement. At any rate I decided to scrap the first-person camera idea and move on.

At this point I decided to abstract my terrain generator function. One can use any function of two variables to generate height maps, and Scala really shines in dealing with functions. First I wrote a trait called TerrainGenerator (TG) that was nothing more than an alias: trait TerrainGenerator extends ((Int, Int) => Float). Then one can write a PerlinNoiseTG for generating terrain from perlin noise; it’s just as easy to write something like SimplexNoiseTG for simplex noise or FuncTG for a generic function. That’s great, but what’s really awesome is writing operators for terrain generators. I’m kind of obsessed with algebra – not the high school “solve 3x+7=12” bullhonky – but with the idea of having a set of objects and then using operators to combine those objects together. You can create beautiful structure from fairly simple rules. This is probably old news for most mathematically inclined people but I’m still new to the concept and it is very exciting :). My combiner class looks like this:

abstract class TGCombiner(tgs:TerrainGenerator*) 
   extends ((TerrainGenerator*) => TerrainGenerator) 
   with TerrainGenerator {

    override def apply(x:Int, y:Int) = apply(tgs:_*)(x, y)


TGCombiner is actually two functions – one takes in a varargs list of TGs and outputs a new TG, and the other is just the TG function (taking in two variables and outputting the height). Probably the most obvious type of combiner is one which performs some sort of operation on each individual height to spit out a new height; the class looks like:

abstract class OperatorCombiner(tgss:TerrainGenerator*) 
   extends TGCombiner(tgss:_*) {

       def op:(Float, Float) => Float

       override def apply(tgs:TerrainGenerator*) = new TerrainGenerator { 
          override def apply(x:Int, y:Int) =, y)).reduceLeft(op) 


I’m not too happy with how apply has to instantiate an anonymous class; I considered writing a subclass of TerrainGenerator to handle this case but I think the problem comes down to either a) having apply take parameters, b) having the class take parameters, or c) not having enough framework. Actually, I’m not really certain about what I am even looking for at this point. There is obviously something weird going on but it’s not clear to me yet. But anyways.

I ended up writing three base TGs: one for simplex noise, one for Perlin noise, and one of two superimposed sine waves. On top of that, I built OperatorCombiners for all combinations of the three base TGs. You can see the sketch here.

The final stage in this sketch was to make it presentable for the wide internet. Applets written in Scala are pretty much unviable due to the requirement of packaging the whole Scala library (2.8.0 is ~6 mb), unless you use some sort of code shinker. Proguard is a great tool for shrinking java files, but it requires a lot of configuration. You have to specify the scala library as one of the input jars, and not as a library jar. Proguard looks at library jars as another source to find references to classes, but it won’t shrink library jars. Alternatively (this is what I do), you can extract all your referenced libraries, including Scala, right into the jar file that holds your applet, and then feed that single jar into Proguard. Proguard will also throw warnings and cancel the operation whenever it runs across a class that it can’t find, which happens several times when it tries to process the Scala library. The only solution I’ve found is to specify the -dontwarn option, which just tells Proguard to carry on despite warnings.
Shrinkers can’t account for dynamic access of classes (e.g. through reflection), which Processing and Proscene (and several other Processing libraries) rely on, so you have to keep specific classes. Originally I tried to keep only the methods that might get dynamically called by Processing but I couldn’t figure it out so I just kept all of Proscene (which was the only offender). I can imagine that there will be a lot of classes one will have to keep in order to keep all of the dynamic access happy, but I haven’t really looked into it. My current configuration looks like this:

-injars Daily.jar
-outjars Daily_Out.jar

-libraryjars 'C:\Program Files\Java\jdk1.6.0_23\jre\lib\rt.jar'


-keep public class * extends processing.core.PGraphics

# Keep Proscene
-keepclasseswithmembers public class remixlab.proscene.* {
    public ;

# Keep all registerXxxx() method callbacks in all classes
# -keep public class * extends java.lang.Object {
# 	public void pre();
# 	public void draw();
# 	public void post();
# 	public void keyEvent(java.awt.event.KeyEvent);
# 	public void mouseEvent(java.awt.event.MouseEvent);
# 	public void size(int, int);
# 	public void stop();
# 	public void dispose();
# }

# Keep Jul08b
-keep public class daily.Jul08b

This shrunk the jar from 8,987 kb to 709 kb, which I’d say is pretty good. Removing -dontoptimize further reduces it to 611 kb, and removing -dontobfuscate even further reduces it to just 439 kb. The size of this blog page is more than that (I checked :P). Quite impressive. As a note, it might be better to hold all of the libraries you might use in one location within the server – that is, putting all of the jars within a single folder somewhere – and then have the applets’ classpath point to those jars. Jar caching would work and the user wouldn’t have to download redundant code when viewing multiple applets; on the downside, new viewers would have to download a large number of libraries right off the bat.

I think there’s a lot of room for exploration in the field of generative content, especially in relation to games. I would LOVE to see randomly generated NPCs, enemies, towns, quests, spells, game mechanics, games, game generating algorithms, algorithms generating game generating… you get the point.