MegaTerrain

#1 No, you just make bigger terrains now, any size up to 2048x2048 at whatever square size you like for detail/area - but it doesn't page from disk, it all gets loaded into memory at once.

At least that's my understanding.

#2 By using heightmaps you can have a terrain of any size (1024x1024 2048x2048 .... 8192x8192 and larger) but keep in mind that very large ones will need more RAM and will hit on performance.

You can also adjust the meters per pixel and have a smaller heightmap create a large one (for example, a 512x512 heightmap with 4 meters per pixel would be a 2048 square meters terrain) - but that hits a bit on terrain quality so be carefull using that.

I think those are the possibilities you have on stock for huge terrains.

I did howecer read somwhere that you can place other terrain systems (like Atlas) into Torque if these two don't suit you.

#3 Well the TGE terrain was 2048 x 2048 and used a 256 x map. I would like to get a 4096 x size so I use a 512 x map and set square size to 8 and it's automagic ?

#4 basicly yes - but like i said - doing it that way will afect terrain quality (might seem a bit blurry) - but depending on your heightmap and your personal quality expectations you might get a good enough result out of it.

Of course a 2048x heightmap at 1 meter per pixel would get better quality - but like i said your 512x might get good enough results - specially if you populate well your terrain - that way the player will not notice the quality lost on the terrain itself and the final result will be about the same with a smaller map.

The difference from the TGE terrain system as i understood is that in T3D there is no max size - as long as your sistem has resources to spare you can make it larger

#5 I can live with the same quality of TGE just would like to have it larger.
So a 4096 x would be 16 megs times 3 verts per = about 50 meg footprint plenty to hold in todays ram space. I guess the only issue is moving that data to video.
Does the engine contain code to do occlusion culling on landscape? If so then lots of hills would hide most of it or setting the fog and far clip plane in a bit.
Thoughts?

#6 The terrain is a geomipmapping alike approach, as such yes there is code that ensures that not the full terrain is pushed to the gpu when not needed.
there is no occlusion culling thought, Frustrum Culling only.

#7 @Howard - Its more than just the verts. The collision structure used in TerrainBlock is heavy... a 4096 really pushes the memory usage and performance of collision.

I suggest to everyone to use less than 4096 if possible.

Also as far as size... the old 'squareSize' value is now unbounded... it could be 0.2 or 20... its not power of two integers like it has been in the past.

Marc is right that the terrain does no special occlusion of itself... which is not all that different than it was before. If time permits we'll try to support special harware occlusion queries for terrain cells as there can be a savings if we avoid drawing them.

#8 There is a collision mesh for the land? Could you elaborate?

Less than 4096 next power of 2 down is 2048 or can we have arbitrary sizes like 3k ?

Is there any occlusion culling like inside a dif with no windows? Or is the whole engine culling on the frustum?

Thanks for all the info...

#9 TerrainBlock has always created a collision structure from its heights. Its not a mesh really.

It will not work with non-power of 2 sizes.

Zoning is still supported by DIFs and soon to be supported by Zone and Portal scene objects.