Multiple Mega Terrain Instances

#1 Mega terrains use a slightly different file format than regular terrains. Though it uses the .ter extension, it points to two .ter files that give it information for edges and corners. (So the blocks match up)

Alternatively, you could use a series of regular terrain files, keep in mind edges are an issue, but I've created maps with up to 64 terrain blocks in them.

#2 If the problem with crashing occurs after you delete an existing Megaterrain block and go to add a new one, there is a fix from Rene Damm for 1.7.1 at this URI: http://www.garagegames.com/mg/forums/result.thread.php?qt=76954

I had terrible problems deleting and creating megaterrains until I applied this patch.

My record for concurrent megaterrains was 16 in one file (getting the edges to match up was a bear, especially if you did any sculpting on the border, so I eventually gave up on the approach).

@Matt Vitelli -- I didn't know that about "slightly different file format. Are there any repercussions to cutting a megaterrain down to just one block, discarding the other three through altering the mission file, that you are aware of?

#3 @Netwyrm - I've seen the thread that you reference and have added these changes without any improvement. I can only assume that I'm doing something wrong.

What I've tried the last couple of times is as follows:

1. create a mission with no terrain blocks.
2. Import a 512 x 512 heightmap as a mega terrain. This works fine.
3. Save it.
4. Attempt to import a second 512 x 512 heightmap. The crash occurs at about the point where it should be finishing the import.

Is this the correct process?

#4 Well, I did it by creating multiple missions, then creating a megaterrain in each, then opening the mission file and copying each megaterrain wrapper with its four terrain blocks into a single mission file. I never tried creating the megaterrains directly in the same mission via the GUI and importing multiple heightmaps.

The problems I encountered were that the edges of the megaterrains did not necessarily meet up, and attempting to use the tools to bring them to a common level was... tedious to say the least. I had some luck carefully matching the heightmaps with exactly equivalent colors along their edges... What I did was take a 1024x1024 map and slice it into quarters while making sure each quarter contained a sample of the highest and lowest value of gray.

The only way all the edges would match perfectly without lots of fiddling about was to create multiple perfectly flat megaterrains, bring them in, and then edit with the sculpting tools between the boundary lines. If you were good with placing rocks or suchlike along the edges to make up the gaps where the terrains couldn't be made to join smoothly, you might get this to work.

My entire undertaking was an experiment in getting a genuine feel for the scale and performance and look of a terrain while trying to learn how a mission map "felt" at those sizes.

YMMV.



Edited for spelling

#5 Wow, that sounds like alot of work! I think if I have to manually edit the terrains I'll continue on with Atlas. At least I understand how to use Atlas. Thanks for the input!

#6 If you look in TerrainFile you can see how it keeps links to the two neighboring TerrainBlocks in mEdgeTerrainFiles. Technically there is nothing that keeps you from making that store 4 edge files and stitching together as many terrains as you like in any pattern.

There are two caveats here.

Each TerrainBlock gets its own ClipMap... and even with very low detail settings the clipmap can take 10-50MB of video memory. People have discussed fixing it to generate one Clipmap for all the terrains, but i have no insight into how to do that.

Also the current TerrainBlock rendering code is stupid slow... more than 4 terrains and i suspect you'll be spending more than 50% of your CPU time on terrain rendering. There is a new rendering path for TerrainBlock coming, but its not ready yet.

#7 Which is why texture clipmapping = bad idea if you're only using 1-8 textures. If this is the case, then why even clipmap at all? You can do your blending during the render stage and save valuable video memory. For anything with a lot of color variation and surface variation (real life satellite imaging, for instance), clipmapping's an excellent idea.

#8 @Matt - Your preaching to the choir man. :)

The problem is that we need to allow TerrainBlock to work with or without clipmapping.

Clipmap can be a win in blended terrains *if* your using alot of layers and your card has crappy fillrate... but in general its not. Its also useful if your baking something other than terrain textures into it... like decals.

Other than that i hate the thing. Since its a fake mipmap that only works based on camera distance things that are perpendicular to the camera get blurry. Also at a distance your terrain textures turn into a smudge. While we've worked around it in the past, in general it sucks.

I had a prototype multipass blend shader working for TerrainBlock, but its not ready for release. I hope to get TerrainBlock clipmaps to be an option in a future TGEA release.

---

Still i don't understand how Id gets "Megatexture" to look so good in QaukeWars... its the thing in the back of my mind that keeps me from totally giving up on the clipmap idea. We must be doing it very wrong.