Terrain tiles (aka... paging Eric)

In our conversation we talked a little bit about creating terrain and while I am currently using the max page size for terrain, I want to do some smarter things with breaking up my world into tile sized pieces. Is there a smart way to implement a terrain tile/page system such that I can page in terrains as the user moves from tile to tile? You mentioned that I would have to implement my own terrain if I did this, but I wasn't entirely sure what you meant.

Do you mean that I would have to implement LOD on each terrain page or that I would have to implement a system where I would deal with paging in the terrain and such?

What advice would you give to someone that wanted to say implement the state of California so that someone could race on it? or even better, if I wanted to implement Cannonball Run on even Oblivion - a huge world that simply wouldn't fit onto one terrain page?

 

You can build a mesh from scratch, as I do in Fractscape. (It also optionally uses the Unity terrain system in 1.1, but I retained the custom mesh because there are still a few things the Unity terrain can't do.) When building from scratch, there are no limits. What you do as far as LOD is up to you; there are a number of different methods commonly used (ROAM, etc.). I would probably start by firing up Google and seeing what's out there. For example, I came across this page before, which has source code for a number of different implementations, though I haven't really looked at any of it.

--Eric

 

Okay, yeah I have a book from a game development class that is dedicated to the roam technique. I was hoping to leave all that stuff behind by using Unity, but they just keep pulling me back in

Do you use ROAM or any similar techniques in your terrain building? I am trying to minimize the amount of time I will have to spend in the terrain engine, and I do want to be able to lay things out in the editor. If I roll my own terrain engine, likely pulling in DEM data - how would I handle laying out stuff on the terrain. Would I have to implement all of that as well?

 

I'd guess with the current terrain system, the goal was to get an out-of-the-box solution that would work well for most people. But not every system is going to cover every situation, of course.

No, the custom mesh in Fractscape only goes up to about 32,000 polygons so it doesn't really have any LOD. (Well, except you can manually reduce the detail if you want, if that counts. )

Yep; one issue is how to handle collisions. The simplest is just to use a mesh collider, but the problem with that is mesh colliders can take some seconds to compute with high-poly meshes. So you would have a pause whenever you made a new terrain tile. I did a little experiment once with threads, and found that it's quite possible to make the mesh collider compute in a separate thread, which eliminates the pauses, as long as you don't mind the collider not being active immediately. The major drawback is that doing this isn't thread-safe, so it crashed about 50% of the time, alas....

If you don't want pauses, then you have to do your own collision stuff. In Fractscape, the first-person mode doesn't use a collider, which is why you can change the terrain while standing on it and it responds instantly. Even when using the Unity terrain, which has a much faster collider than a mesh collider, I elected not to use it, in the interest of keeping my code basically the same. Instead, I have a function that essentially does the same thing as Terrain.SampleHeight for the custom mesh, which is what I use for the "collision". So I just added one line that actually returns a value from SampleHeight if you're using the Unity terrain, and everything else works exactly the same.

--Eric

 

Hmmm... losing tool support makes the whole exercise a non-starter. I don't want to have to build tools to put textures, grass, etc on the terrain. That would take more time than I really want to spend on this demo.

Hmmm.... decisions decisions

 

Okay, so I'm just going to implement my on terrain engine on ROAM again. I've fought with this design decision for a while, but this is the only way to build the type of game I need to build.

I have implemented the code to simply bring in different terrain tiles from a master file which contains the entire world (so I'm chunking the terrain on the fly as the player moves around), but I have no idea how to get this to display properly in Unity itself. I'm still using Unity Indie, is this going to be an impediment to me making this new terrain engine display in Unity proper? Will I need plugin support in order to create new tools so that I can as texture, trees, and grass to the terrain?

 

Nope. Most of Fractscape, for example, was built with Indie...I only got Pro about a week before I was done with 1.0, and the only extras I did with Pro (in this case) were water reflections and the underwater rippling effect in Fantastic mode.

Nope again. You can take a look at this thing I did quite a while ago. It was long before Unity 2.0 was released, so everything had to be built with the mesh scripting interface (except the terrain, which is just a model). I was still pretty new to Unity at the time, so it could have been done much better, but at least it shows some of what's possible.

--Eric