Three.js - Procedurally Generated Infinite Terrain
Performance
The saying goes that "premature optimization is the root of all evil".
The saying goes that "premature optimization is the root of all evil".
A few months ago I experimented with using Blender to create 3D models. First, I created a tree that you can see in previous posts. Then I had the idea to create a "troll", that could be used in a game. I followed Blender tutorials and created a humanoid model. Then I rigged the model to move naturally. Finally, I created two animations with the model. One while standing still, and one while walking. I'm proficient with web graphics and photoshop, however after finishing the model I gained a greater respect and understanding for the amount of work that must go into producing assets for a large scale game. This is partially how I came to start experimenting with procedural generation techniques. Before doing that though, I wanted to animate my model. Hopefully this post will help some people trying to animate models from Blender.
Lately I have been working on another Three.js + Node.js project that involves terrain generation similar to Minecraft. In order to create interesting terrain I am using 3D Perlin noise. It's basically an algorithm that takes some coordinates, and generates natural looking noise in 3-dimensional space. It's supposed to return values in the range [-1, 1]. One way to turn this into terrain is to add the value to the height of the land, and turn everything that is less than 0 into land. However, early in the project I ran into an interesting problem that doesn't seem to be documented anywhere else on the web.
This was a bit of an annoying problem and something that I needed to solve. Playing with the parameters didn't seem to yield any results that I could tell... and { screenCoordinates: false, affectedByDistance:false } was the only thing that made the sprites look remotely normal. So I needed to take a look at the inner workings of sprites in Three.js. This was a bit difficult since I hadn't done any openGL or low-level WebGL yet, but now you get to follow along.
You can look at the full Three.js source code on github here. I'll be posting snippets as we go along.
So far we have a very basic landscape and the ability to capture screen coordinates in an 3D world displayed isometrically. Now it'd be nice to have some interaction available. I started by just making a ball roll to whatever point I clicked. Three.js makes this easy.
However, my code had begun to get pretty messy. I decided that Backbone.js could help with my problem. Backbone.js is a lightweight javascript MVC framework that I've been using in other projects. I would highly recommend taking a look at it. If you're used to something like Rails the views in backbone.js are more like controllers. The models are models, and the views are javascript templates. Here we won't take full advantage of the power of Backbone.js since we won't be using templating or models, but it will sure help organize our code.
Let's create a global object for our app. We'll organize this object into Models, Views, and Controllers.
In my previous post we started off pretty simple, just to display a landscape with a tiled texture. The next step is to create some movement. At first, I decided that my character would move by a mouse click at the desired destination. Nothing too complex, the character will move from their current position to the destination position every update. But first, we need to translate screen coordinates which are 2D to 3D world coordinates. If you don't understand orthographic projection too well this can be more difficult than it sounds.
Most 3D games use perspective projection, which means that objects will become smaller as they become farther away. This is how we see things in the real world. In this case, we can imagine all the visible points in 3D space being mapped to a shape called a frustum ( http://en.wikipedia.org/wiki/Viewing_frustum ). In this case, when we transform a 3D point to the screen we multiply the point by our projection matrix and the inverse of our world matrix.
Then, we can just multiply the point by our world matrix and the inverse of our projection matrix and we get the same point back. When using screen coordinates things become a bit more complex because we throw away the z value. Screen coordinates don't have one since they are in 2D. However, we can just fill in a z value such as 0.5. Then we find the vector from the camera to our unprojected point. We look for intersecting objects to tell what the user has clicked on.
The above technique is commonly used, however it won't work for an isometric projection.
Previously, I've worked on large javascript applications that make tons of manipulations to the DOM manually or store lots of HTML as a string. When these pieces of code pieces grow they become a huge pain to change and maintain. Javascript templating to the rescue! I've been working with both jquery-tmpl.js and handlebars.js and want to offer a simple comparison.
First, a little background. Jquery-tmpl is the official jQuery templating plugin as of October, 2010 and is hosted in jQuery's github. Handlebars is an extension to Mustache.js with more features. A mustache.js template is a Handlebars template. Mustache.js is a templating system that has been implemented across many languages. You can find more about these plugins at the following links.
jquery-tmpl.js - http://www.borismoore.com/2010/10/jquery-templates-is-now-official-jquery.html (and you can take a look at jQuery docs).
handlebars.js - http://handlebars.strobeapp.com/ (To download handlebars.js go to this here https://github.com/wycats/handlebars.js/downloads)
mustache.js - http://mustache.github.com/
In the examples I'll be writing my templates in a script tag with the type set to something that the browser cannot recognize (x-jquery-tmpl or x-handlebars-template). You can still write the templates as html inline to javascript, but I don't prefer this method for anything but the simplest templates for the reasons stated above. Also, Jquery-tmpl will be the first block of code, and Handlebars will be the second block of code.
