I thought a good way to get back into development would be to re-familiarize myself with the height map system.  It turned out to be a good place to start because I wasn’t 100% on how it all worked but now I think I am.  Small changes in the red value on the maps make huge differences in the terrain height.  Changes to the green value are mid-range.  Changes to the blue value as pretty minuscule.  This was the intended design, but I may have had the blue and green values switched.  I’m not really sure, but in any case it is correct now.  Also, it turned out my game code works just fine with the newly created height maps.  So I can make something in GIMP, upload it, then run around on that terrain in the game world.

Since I’m clear on the terrain system, my next step is to improve my terrain editing tools.  I can use an image editor like GIMP, but it’s not practical.  The difference between [r,g,b] values of [128, 0, 0] and [129, 0, 0] (or 0x800000 and 0x810000 in hex) is virtually invisible to the human eye, but it’s a height difference of 256 meters in the game world, which is a pretty big deal.  I already have a mechanism to raise and lower individual terrain vertices, but I need to develop something more like a brush tool that can be resized and dragged across the terrain to raise or lower multiple points simultaneously.  This will be a little complicated to implement, but with that tool I’ll have a real terrain editing system and I can move into asset placement tools, which will be much more fun.

The last few weeks have been unproductive from a development standpoint but I’m going to start back up soon.  Since I’ve worked out the basics of the height map system my next step is to polish the world editor so that I can make a real terrain and put some actual assets into it.  It will be rudimentary at first but I need a somewhat finished product produced by the world editor to keep me motivated to stay moving ahead.

I’ve been working on loading and saving height maps for terrain lately.  My first attempt at this just used a grayscale image and the engine read the [r, g, b] values from each pixel and placed the corresponding terrain vertex at the appropriate height.  This works fine but it’s not a very efficient use of the image data.  Since the image is grayscale each pixel’s [r, g, b] value is the same number repeated three times.

I don’t care so much about the inefficiency but the lack of resolution was annoying.  What I mean is that in a grayscale image each pixel is somewhere between [0, 0, 0] (ignoring alpha values) and [255, 255, 255].  That means the world’s terrain can only have 256 distinct height values.  This can be scaled arbitrarily so I might have each step set at 0.1 meters, but then the highest point in the game could only ever be 25 meters.  Actually, it would be half of that since the terrain has to be able to account for distances below sea level as well.  Or I might have each step be 2 meters so that I could have towering peaks of 256 meters and abyssal depths of 256 meters, but the terrain itself would jump up and down by increments as high as player characters are tall, so neither of these is ideal.

Since this is quite insufficient for a world that’s at all interesting I have been looking at other options.  My first though was to just add r + g + b to get a range of 768.  Divided in half this gives me a max height of 384 meters.  I could live with this and just accept that Lyridia is a fairly flat place but my terrain step distance would still be 1 meter, and I just don’t think that would look very good.  Again, I could scale this down but then my max height goes down and the world gets pretty flat and boring again.  Plus, with this method a pixel with color [255, 0, 0] represents the same height as another with [128, 127, 0] or another with [0, 255, 0] or another with [2, 0, 253].  With so many colors representing the same ultimate value I knew there had to be a better way to store more resolution in a standard image.

I kept coming back to the number 16.7 million in my head.  That’s the number of possible color combinations for a 24 bit monitor.  It’s 256 x 256 x 256.  With that in mind, I figured there must be a way to get 16.7 million discreet levels in a world terrain and this is (I think) how you do it.

For any pixel, the [r] value has the largest effect.  I thought it would be fun to have a maximum terrain delta of 65,536 meters, so I multiply each [r] value by 256 to get r.  Then each [g] value is left unmodified as g, then each [b] value is divided by 255 to get b.  Now just add r + g + b to get your terrain height.  No need to scale anything as this gives you a massive delta by altering the [r] values but extremely fine gradations by altering the [b] value.  A terrain height represented by [0, 0, 1] is just 0.003922 meters high!  That’s less than a quarter of an inch.  Yet [255, 255, 255] is over 40 miles high!

This may all be incredibly obvious to anyone who has done this type of work before but that’s definitely not me so it was fun and challenging to figure out how to make this work.  The long and the short of it is that I can store height maps for Lyridia as standard .png files with more resolution than I’ll ever need and I’m pretty excited about that.

I’m still working on the world editor.  I’ve made some real strides in the terrain editing functionality.  Now you can save a terrain and it produces a height map that can then be loaded by the world editor.  I’m still trying to work out all the specifics of how to make this work exactly the way I want it to, but I’m sick today and I don’t have the patience to work on it right now, so I’m really just posting a “no update” update.  I guess it’s better than nothing.

I’m continuing to improve the terrain editing functionality of the scene editor.  Now when you click on a terrain object instead of changing the emissive value so that the terrain glows, a black wireframe is laid over the terrain object itself.  Then, if you press ‘e’ to enter edit mode, the wireframe turns light gray, as in the picture:

This is a better way to do things because it doesn’t mess with the color of the terrain as it is being edited.  When the terrain was glowing a bright green, it made it difficult to see the changes being made.  Now you can tell what you are doing, and the wireframe really helps.  I also change the camera to orthographic.  This just makes it easier to navigate and get a clearer picture of the whole scene.  The white square with line in the image is a directional light helper.

Right now I’m running into a little trouble with saving the scene file.  For simplicity’s sake I was trying to just save the ‘y’ value of every vertex in the terrain.  This isn’t working correctly and I think it’s because of an inherent limitation in the amount of data I can send through an HTTP POST.  I may have to write the scene file data into a pop up <div> then copy and paste that into a scene file on the server.  This isn’t very efficient so I’ll need to improve the process eventually, but it may be an ok solution for now.

Check this out:That’s a genuinely terrible excuse for a terrain but it was generated completely in the editor.  For now right clicking on a terrain while in edit mode raises vertex closest to your click by 2 units.  This obviously needs to be expanded to allow for arbitrary up and down movement, but it’s a start.  The terrain object’s vertex and normal arrays have to be recomputed every time a vertex is moved, but this works.  After the controls themselves are improved a little, I’ll need to write a way to export this terrain to a height map.  Then I’ll have to make a way to import those height maps back into the editor.  Lots to do.

I’ve been working on terrain editing tonight and it’s been a little slow but I’m making progress.  Now when you select a terrain object you can hit ‘e’ to enter edit mode.  This changes the emissive color of the object so you can tell you are in edit mode.  Then, when you right click anywhere on the terrain it picks the vertex closest to where you clicked and places a little yellow sphere there.  The sphere is, of course, just a placeholder for future functionality.  Eventually I will be able to move the selected vertex up and down along the y axis.  This is actually a pretty small step to code, I just don’t feel like it tonight.

This isn’t anything groundbreaking but I thought somebody might be interested in how to select the closest vertex on a mesh.

First, you need to get an intersection point.  There are plenty of resources out there on how to do this, just search for raycaster, and specifically the .setFromCamera() method.  Anyway, once you have your intersection object it tells you some interesting things.  First of all it includes the intersection point, which is obviously necessary.  It also has the intersection face.  The face is comprised of three elements; a, b, and c.  These are the indices of the three vertices of the triangle intersected.  So to get the actual Vector3s for these three points you can do something like this:

var a = terrain.geometry.vertices[intersections[0].face.a];
var b = terrain.geometry.vertices[intersections[0].face.b];
var c = terrain.geometry.vertices[intersections[0].face.c];

Now you have the intersection point as a Vector3 and the three points of the intersected triangle, also as Vector3s.  Vector3 has a convenient method called .distanceTo() that returns, you guess it, the distance from one Vector3 to another.  So all you need to do is find out which of a, b, and c is closest to your intersection point.  I used Math.min() but there are plenty of ways to do this.  Once you know the closest one, you can do whatever you want with it.  As I said previously, I placed a little yellow sphere on the closest vertex for now, but the eventual goal is to move the vertex up and down to shape the terrain.

Maybe this will be mildly useful to someone down the road.  If you have any questions about this leave a comment and I’ll do my best to respond.

Translate, rotate, and scale are working for all objects.  Only one object can be selected at a time, so if you have an object selected and select another, the first is automatically deselected.  Saving and loading a scene with translated, rotated, and scaled objects is working.  I realize these are small steps, but they are definitely steps in the right direction.

Next I need to get some simple terrain editing in place.  The terrain is a selectable object just like everything else right now but that needs to change.  I’ll have to have special controls for it.  Initially I want to be able to select a vertex in the terrain and move it up or down.  Eventually I want to be able to select a vertex and have a simple proportional editor that moves adjacent vertices, well, proportionally.

Before that I might want to add some basic camera controls.  It would be nice to be able to swap back and forth between perspective and orthographic views, and it would be nice to be able to look down at the scene from above with a single keystroke.  We’ll see what I feel like working on tomorrow, I suppose.

Now when you select an asset and then translate (‘g’) or rotate (‘r’) and then select an axis (‘x’, ‘y’, or ‘z’) the action happens when you move the mouse left or right.  So if you want to move something along the x axis you select it, press ‘g’ then ‘x’ and move the mouse.  Also you can save a map and load a map.  It’s saved in JSON format so it’s pretty easy to work with in the actual editor and the PHP that actually writes the file.  Still lots of work to do but I’m making real progress toward some basic functionality.