The world editor is really starting to come together.  Here’s the latest:

It’s still pretty rudimentary, I realize, but in the editor I can now hit the little “Load Scene” button in the menu at the top and it opens a box that lists scenes that are available to load.  It then reads the scene file and the associated height map and creates a terrain and adds any objects from the scene file to the scene itself.  That white thing is a light helper that will probably eventually go away.  Once the scene is loaded you can rotate around, pan, and zoom to your heart’s content.  Again, I know this is pretty basic stuff but it’s cool to me that I’m emulating some of the basic functionality of Blender but in a browser.  I now need to implement that button that says “Add Asset” so that I can actually add stuff to the scene.  I also need improve the tools to manipulate objects in the scene, add lights, improve the terrain editor, etc., etc., etc.

Also, GIMP 2.10.0 is out and looks great so far.

Also, happy birthday Josh!

I’m still working on the world editor.  I got the camera rotation, panning, and zooming working pretty much exactly the way I want, and I put a little octahedron at the point of the camera target just so I can tell where it’s looking.  Now I’m working on a UI design for the editor.  So far I’ve created a little menu at the top of the screen with a few options and some drop-down options too.  I also added a dynamic box so that I can select which chunk I want to edit.  As a side note I’ve finalized that the chunks are 1,024 x 1,024 meters, and the center of the world is at chunk [127, 127].  Assuming that the world extends out equally from this point, which is not strictly a requirement moving forward, it is 256 x 256 chunks.  That’s a square world that is 262,144 meters on a side, or 162 miles.  The total potential area is over 26,000 square miles.  That’s actually way, way too big to fit within the lore of Tright.  Lyridia will actually be closer to the size of Jamaica, maybe around 4,000 square miles.  That’s still almost 100 x 100 chunks.  There’s is absolutely no way I would be able to create 10,000 chunks of content by myself, but that’s ok.  If I make a settlement on the east edge of the island and then one on the west edge I don’t necessarily have to create all 98 chunks in between them, so long as players can’t venture into areas that don’t exist.

I started to not work on the game tonight but I’m really glad I did.  In the world editor now you can pan, rotate, and zoom the camera.  Rotate and zoom both work pretty much perfectly at this point.  Panning also works, but doing so moves you along the x and z axes no matter the camera’s orientation.  Obviously I want the camera to pan along the axes of the camera’s viewport, but I think that should be relatively easy to implement.  Other than that it is really quite cool to be able to zoom in and out and rotate around the scene to see things from any angle.  Of course, there’s nothing to really see at this point other than a really basic test terrain, but it’s a start and I like it.

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.