Now In Eye Popping 3D!

It took a little bit of fighting with bugs that weren’t showing up in the 2D view, and a bit of time to figure out what was going on with the lighting system in JME, but I finally got the 3D display of the fractal landscapes working.

The first stage was just displaying each node as a discrete point so I could see that each was in about the right place. It looks a little bit like this:


Fractal landscape as points (click for bigger).


I did this by simply piping the spatial coordinates and colour information of each node into a pair of standard Java FloatBuffers, passing these to a JME Point class (which should really be called PointSet, in my opinion) and attaching this to the root display node of my JME application. The colouring scheme is the same as the one used for the 2D display. Some things don’t look quite right, largely due to the fact that I’ve just drawn the “underwater” points as blue, rather than adding any actual “water.” Don’t fret, it’s on the todo list.

That said, the landscape looks about right. All the points seem to be in their correct location. As a quick implementation note, I’m defining the (x, y, z) coordinates of the scene in the following way:

x = east

y = altitude

z = -north

With some scaling factors used to map the values from the [0,1] range used to address them to slightly more real world like dimensions.

The next stage was to display the landscape in wireframe to make sure the connections I’ll be using create a more solid looking polygon based display are all working correctly. Why not just go directly to polygons? You can see the the detail better in the wireframe display, making debugging much easier. I’ll definitely be using it again later.

This time, instead of piping each and every node into the vertex array, only the nodes at the highest level of detail are used. These are the nodes generated during the final “square stage” of the fractal algorithm, for those of you playing at home. Each draws a triangle (consisting of three separate lines) into the vertex buffer for each pair of parents it has in the landscape. The result looks something like this:


Fractal landscape as lines (click for bigger).


Everything seems to be in good order there, I think. One or two things don’t look quite right, particularly the beaches, but the tessellation and coverage of the polygons looks right. Here’s a closer in look at some of the polygons so you can see what the tessellation scheme actually produces:


Polygon tessellation (click for bigger).


You can (hopefully) see that each of the “active” nodes sits at the centre of a diamond formed from the shape of its parents, so it’s the points with four lines branching from them (rather than eight) which are actually being used to draw the scene.

Next: polygons. Again, only the nodes at the highest level of detail are used. This time, each inserts itself into the vertex buffer, then adds its parents if they’re not in there already. Each node remembers its postion in the vertex buffer, and these indices are then used to draw the actual polygons. These are declared by passing the indices in sets of three into a standard Java IntBuffer. The buffers are then passed to one of JME TriMesh geometry classes and displayed, like this:


Fractal landscape as polygons (click for bigger).


Again, the beaches don’t look quite right, but otherwise I’m reasonably pleased. I still need to add the actual water and improve the form of the landscape itself (and about a million other things), but in terms of display this is looking pretty good. Except for one thing: I’m using far more detail than I need to. Let me illustrate this with a slightly more extreme example. The pictures I’ve posed so far were generated using seven iterations of the diamond square algorithm. Here’s what happens when I use ten iterations (remember, the number of points increases exponentially):


MOAR POLYGONS! (click for bigger)


On the bright side the beaches look better, but that’s a lot of polygons. Far more then we actually need to display. 1579008 polygons, in fact. We need to reduce that somewhat, if we’re going to make things more complicated and maintain a reasonable frame rate (I’m getting about 60fps with this view at the moment). You can see the problem more clearly if I show you the same view using lines rather than polygons:


MOAR LINES! (click for bigger)


You can just about see the individual triangles up close, but further away the lines just mush together. I think we can afford to reduce the level of detail as we get further away, don’t you?

Well, I’ll get right on that, then…


You’re Speaking my Language, Baby. Part 2: Java.

Author’s note: As this post started out HUGE, it’s been split into parts. You’ll find the introduction here.

The first language I’m considering is Java. This is by far the language I’m most comfortable and proficient with. It was used for about 90% of my Bachelors degree, I wrote the entire codebase of my PhD using it, and it gets used here and there in my day job. I’m comfortable with Java, and find it to be quite a pleasant language to program in. Big tick on the question regarding my ability to use it, then. Java has some modest dynamic capabilities built in, but it also has a lot of small options for using higher level languages for the scripting, the cleanest of which is possibly Groovy.

Java has a bad reputation performance wise, but this largely isn’t true any more. It does run using a virtual machine, but is compiled to native code at run time. It’s a lot easier to write good code using Java than the other languages I’m considering, and that can help with performance a lot, but in general Java has the potential to be the slowest of the three, all things being equal.

Tools are actually not a problem. There are a lot of high quality graphics engines available for Java, with the Java Monkey Engine (JME) being my favourite. A physics add-on is available in the form of JMEPhysics, with the next version slated to have a physics engine baked in. Raw OpenGL is also an option with LWJGL, should I want it. Likewise, I suspect that the Red Dwarf Server is likely meet my communication needs.

The applicability of Java to other interested parties is an interesting question. A lot of software gets written in Java. A LOT. But the vast majority of it is not games. Largely, I think this is because it’s perceived to be lacking in the performance department. It’s also a little harder to protect you code when you’re writing in Java, too. The previously mentioned JME has the support of a commercial games company, though, so clearly there is interest. Computers are getting faster at quite a rate, so performance has the potential to be less of a concern, especially if the project you’re working on has the whiff of a server side application about it. When it comes to server side code, I think Java is definitely winning the race. Frankly, I have a bit of trouble calling this one either way.

One language down, two to go. Look for the next post tomorrow (here), should you be interested in such things.