VectorStorm Blog

Of course, immediately after posting about the weird new glitch, I figured out what was causing it;  under my new setup, I was usually ending up with districts considering themselves to be neighbors of themselves.. which meant that they were always performing a three-way blend between themself, themself, and their neighbor, instead of fairly blending just between themself and a neighbor;  this was causing each district to unfairly bias toward its own terrain settings.

Now that I’ve fixed the “No, you’re not your own neighbor” bug, I’ve run into a new, more subtle one.  You  might be able to see it in the screenshot above (or to the left, depending on just how wide your browser window is), but I’ll include a screenshot here that makes it much more visible:

In this shot, you can see a weird sharp corner in the height map.  For some reason, the district at the bottom part of the screen isn’t blending into the high ground at the top of the screen, the way that the districts on the left and the right are.

If you view the full image, you’ll see dim blue lines which are the district boundaries (they’re drawn far below the terrain and I’m not looking straight down, so they don’t line up precisely, but I hope you can see what’s going on);  that bottom district isn’t blending with the higher top district because it doesn’t share any edges or vertices with that top district, but it’s still less than the blend distance away from the top district.

To fix this, I think I’m going to have to throw away the whole concept of blending between the current district and all adjacent districts;  instead, I’m going to have to switch to something more like “blend between the current district and all other nearby districts, even if those nearby districts don’t actually touch my borders”.

Complicated!

So I was working to debug terrain blending, and thought that it might be easier to see what was going on if I could see the distances more easily, and so modified the terrain to draw with a simple grid on it…  I’m going to have to include something like this in the final game, aren’t I?

Anyhow, I found a bug in the terrain blending code, and was all excited to have fixed it, only to discover that fixing it has made the problem worse.  Or at least, it has made problems appear at all district boundaries, instead of only at some of them, and make the bad behaviour even more pronounced.

However, making a bug’s bad behaviour occur more consistently is often a good first step toward solving the bug, so I’m hopeful that I’m moving in a good direction.

What I’ve done in this shot is to set up all districts to be almost completely flat, just at different heights from each other;  the blending function should make smooth ramps up and down between the different flat sections.. but as you can see here, the ramps seem to only be about half as steep as they need to be, and you end up with a sheer vertical cliff in the middle of them.  (for reference, the blend between districts occurs over forty meters on each side of the border, and each square in the grid is eight meters on a side — so that means that you should see about ten grid squares of blending in total, between each pair of districts.

Inside VectorStorm, there’s a function vsClamp;  it looks like this:

#define vsClamp(a,min,max) ( vsMin( max, vsMax( min, a ) ) )

(modified for legibility;  C/C++ coders, no need to warn me about how painfully dangerous that code snippit is. )

You’d use it like this:

vsClamp(1, 0, 10)  -> 1
vsClamp(0, 10, 20) -> 10
vsClamp(6, 2, 3)   -> 3

Effectively, you give it a number, and then a minimum and maximum legal value;  the value that pops out of the other end is the original number, clamped to within the requested range.

But what I’ve just discovered is that about half of my code is actually calling this function like this:

vsClamp( min, a, max );

That is, it sandwiches the value to be clamped between the minimum and maximum values.  Which actually makes a weird kind of sense, but isn’t how I actually implemented that function.  ”Oh no,” I thought, “all that code is going to be doing totally the wrong thing”

But as it turns out, calling vsClamp(  a, min, max ) is identical to calling vsClamp( min, a, max ), which is itself identical to calling vsClamp( min, max, a ).  As long as whichever value you intend to act as the ‘min’ is less than whichever value you intend to act as the ‘max’, all three are guaranteed to return the same result.

How bizarre is that?  :)

Happy holidays everyone!  I’ve had a quiet couple of days (at least, in terms of development!), but now that boxing day has come and gone, I’m back to poking around with MMORPG Tycoon.  In the screenshot here, you’re looking at a couple of mountainous districts, separated by a couple of dead flat districts.

And I’ve pretty clearly got a bug in my “terrain blending” code, which I’m pointing at in the screenshot above; precisely halfway through the blend from flat ground to mountains, there’s a steep ridge, just over the border between districts.  (You can see a similar ridge on the mountainous district in the background).  I’m kind of baffled about what’s causing this.  When things like this baffle me, I find that the best thing to do is to stop thinking about them, and work on something else instead;  the answer will eventually come, as long as I’m not banging my head against the problem.

Instead, I worked on my main concern;  editable terrain.  Here’s the problem:  MMORPG Tycoon’s terrain is handled in chunks;  basically large squares of terrain, each currently about a hundred meters on a side.  The problem is that regenerating terrain is extremely computationally expensive, especially with the new blending between districts;  regenerating just one of them currently takes about 60 milliseconds;  enough to make the frame rate stutter quite noticably (basically a frame rate drop from 60fps to about 15 fps).  If that happened every time a player made a terrain modification, then crafting your world would quickly become extremely unpleasant.

So what I did today was to set up terrain calculations as a background process, more like how regular video game streaming works;  the game registers a request for a bit of terrain to be generated, and then several frames later, the terrain generation process informs the game that the data has been generated and can now be used.  This makes the code a good deal more complicated, but it does smooth out those jumps in frame rate.  (In fact, on my computer, I’m now able to hold 60fps, even when regenerating terrain, even in unoptimised debugging builds of the game..)

Anyhow, that’s all for me for today.  I’m going to distract my brain a bit with a book, and hopefully it’ll work out the weird terrain blending problem on its own.  :)

So I’ve got a first pass at smooth transitions between SubRegion patches in place (there are about six subregions visible in this screenshot), and I’ve reached two conclusions:

First, you can get some pretty epic landscapes really easily this way.

Second, it’s way too slow in its current form, and will need some extreme optimisation.  The slow bit is creating an interpolated “Terrain Style” for every terrain vertex which is in a border between subregions… mostly to do with interpolating terrain colors, which is complicated due to the 4D color space with flexible gradients that I’m using.

But I’m sure I’ll think of some optimisations for these calculations.   I’m pretty sure that this is the right direction for me to be going;  just need to solve the tech issues.  :)