{"id":784,"date":"2011-02-13T20:15:52","date_gmt":"2011-02-14T03:15:52","guid":{"rendered":"http:\/\/the-witness.net\/news\/?p=784"},"modified":"2011-02-22T01:10:06","modified_gmt":"2011-02-22T08:10:06","slug":"a-glimpse-into-the-terrain-design-process","status":"publish","type":"post","link":"http:\/\/the-witness.net\/news\/2011\/02\/a-glimpse-into-the-terrain-design-process\/","title":{"rendered":"A glimpse into the terrain design process."},"content":{"rendered":"

This is an experiment in writing up a blog post for a development task while I actually perform the task! \u00a0So right now, as I start writing this, I don't know how it will end!<\/em><\/p>\n


\n<\/em><\/p>\n

I was talking to David Hellman about the game the other day, and he was asking when the island was going to become less like a flat plane where you can just walk to any destination from anywhere else.<\/p>\n

It's been on my to-do list for a while to add more topology to the island. That week I had been working on an area full of puzzles, and I wanted the buildings that define this area to have more of a purpose than they currently do; a topological purpose seemed like the right thing.<\/p>\n

So I figured I'd add a canyon, and the building containing these puzzles would also serve as a bridge across the canyon.<\/p>\n

The natural way to build the canyon in this engine is to shape it out generally with terrain control points, and then make the walls steep by putting mesh objects in there (so that you can't walk up them, and so that the walls of the canyon won't look super-distorted the way heightfield terrains usually do when there are steep slopes.)<\/p>\n

Here was the first cut at it:<\/p>\n

\"\"<\/p>\n

<\/a><\/p>\n

<\/p>\n

As you can see, there are a lot of weird ripples and curves happening there. This is what signal processing people might call \"ringing\". What's happening is that the Kriging system that we are using for terrain modeling is always trying to reconstruct a smooth function, but what we are trying to build here is a discontinuous function (or else a function so steep that it has a lot of high frequencies in it).<\/p>\n

There are a number of ways that one might fix this, but the cheap and hacky one, which would work not only for Kriging but for any other terrain modeling stuff we might stick in in the future, is to add the notion of separating planes that represent discontinuities in the terrain. When evaluating the height of the terrain at any point, we just ignore any control points that are on the other side of the separating plane.<\/p>\n

Adding discontinuities has been on my to-do list since last year when Kriging was added to the engine. It was pretty obvious that it would be needed eventually, but in the spirit of getting things done and not rat-holing on technology, I chose to put it off for as long as possible. But it makes sense that if we are starting to add more topology to the island, we are going to want to have more steep places, and so it's time to add this.<\/p>\n

(We've already had this steepeness problem before, though: if you look at this plateau that is near the camera in our regular island snapshots, you'll see that the whole thing is made out of mesh objects, rather than terrain; we did this in order to avoid this very same ringing problem:)<\/p>\n

\"\"<\/p>\n

It didn't take long to add discontinuity entities into the editor; here's how they are represented:<\/p>\n

\"\"<\/span><\/p>\n


\n<\/span><\/div>\n

To start with, I just used a really dumb heuristic to decide when control points should be excluded. When we use this, here's the result:<\/p>\n

\"\"<\/a><\/p>\n

There is still a bunch of heightfield terrain sticking out. What's going on? If we look back at our red discontinuity planes, it is clear that there are some terrain sample points inside the canyon that are getting treated as if they were outside:<\/p>\n

\"\"<\/span><\/p>\n


\n<\/span><\/div>\n

What's going on is that my simple criterion said \"if you are on the opposite side of a discontinuity plane from a control point, ignore that control point\". The problem is that I am treating them as infinite planes, so those points that you see, which are in front of one plane, are actually outside a neighboring <\/em>plane, if you were to extend that plane infinitely. This is no surprise; I knew it would be a problem, but I am always about implementing the simple thing first and seeing what happens. But now I need a heuristic that will fix this problem.<\/p>\n

One solution would be to combine the discontinuity objects into sequences of points, and then do some more-heuristicky things that may be easier because we have an ordering between the points. \u00a0But I don't want to resort to that if I don't have to, because that may make the system less general, and may make it harder to edit. \u00a0(Then again it may make it easier to edit, because we have editor support for paths! \u00a0But if we want to, we can easily go the other way, from a path down to individual slabs, so it's better to take the most-primitive thing as input if we are able to.)
\n<\/p>\n

\"\"<\/span><\/div>\n

I added a check that would make discontinuity planes irrelevant if the sample points are closer to the side planes of these very thin slabs than they are to the face planes. \u00a0In theory that would at least help, but upon running this, the scene looked almost exactly the same.<\/p>\n

Then upon further investigation I found that I was computing totally wrong planes in the Kriging code; I was transforming the coordinates incorrectly, and so the planes were not in fact where the red slabs in the picture would show them to be. \u00a0I fixed this:<\/p>\n

\"\"<\/a><\/div>\n

Ahhh, much better. \u00a0This seems like it will be good enough for now. \u00a0There's still the question of how to seamlessly blend the heightfield terrain into the mesh objects, but that can wait until closer to ship. \u00a0For now, it doesn't need to be pretty; it just needs to let us build things of roughly the right shape.<\/p>\n

<\/p>\n

The heuristic I use for discarding points is still pretty simplistic and may cause problems. \u00a0My hope is that most of those problems can be worked around just by changing the planes a bit. \u00a0If that turns out not to be true, a little more work will need to be done here!<\/p>\n","protected":false},"excerpt":{"rendered":"

This is an experiment in writing up a blog post for a development task while I actually perform the task! \u00a0So right now, as I start writing this, I don’t know how it will end! I was talking to David Hellman about the game the other day, and he was \u2026<\/p>\n

Continue reading<\/i><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[4,7],"tags":[],"_links":{"self":[{"href":"http:\/\/the-witness.net\/news\/wp-json\/wp\/v2\/posts\/784"}],"collection":[{"href":"http:\/\/the-witness.net\/news\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/the-witness.net\/news\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/the-witness.net\/news\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/the-witness.net\/news\/wp-json\/wp\/v2\/comments?post=784"}],"version-history":[{"count":10,"href":"http:\/\/the-witness.net\/news\/wp-json\/wp\/v2\/posts\/784\/revisions"}],"predecessor-version":[{"id":796,"href":"http:\/\/the-witness.net\/news\/wp-json\/wp\/v2\/posts\/784\/revisions\/796"}],"wp:attachment":[{"href":"http:\/\/the-witness.net\/news\/wp-json\/wp\/v2\/media?parent=784"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/the-witness.net\/news\/wp-json\/wp\/v2\/categories?post=784"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/the-witness.net\/news\/wp-json\/wp\/v2\/tags?post=784"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}