Torque has always been known as an engine with superior support for outdoor scenes. The cornerstone of this support has always been robust terrain engines - from Starsiege to Tribes 2, terrain has been a major component of Torque games.
With this in mind, TGEA has two distinct terrain engines. The first, the legacy terrain engine, is simply a port of the TGE fixed function terrain engine, with some optimizations for shader-enabled cards. The second, the Atlas terrain engine is a rewrite from the ground up, designed to support very large visible distances, expansive terrain datasets, and large, unique textures.
Legacy terrain has the benefit of having a full set of interactive in-engine editors. This made it very easy to work with the terrain, tweak it, and so forth. Atlas, on the other hand, has a separate set of tools and procedures for terrain generation. Despite the lack of in-game editing of Atlas terrain, the tool pipeline for generating the required data is more flexible.
A common method of generating Atlas data is to create the terrain in a 3rd party application, such as Terragen or l3dt. From there, you'll convert the data into Atlas "chunks" and generate the texture trees that cover the huge amount of terrain.
Lightweight CPU Usage
Atlas uses less than 10% of CPU time per frame to update and render. Compare this with approximately 30% for legacy terrain.
Supports landscapes of arbitrary size, bounded only by disk space. The current system supports approximately 10 quinquagintillion (or ten thousand quintillion vigintillion for those Brits in the audience,
or 10^154 chunks on the base level).
Vast View Distances
Can quickly render unlimited view distances, bounded only by the working range of the video card's Z-Buffer.
Atlas can achieve 100+ fps on a midrange Radeon, with a view distance of approximately 4,000 meters.
The legacy terrain is not even capable of rendering this view distance by default!
Atlas supports a single massive texture for your entire terrain! Every texel is unique.
Support for extremely large textures (in excess of 32,768 by 32,768 pixels) on all hardware.
Of course, all this is streamed, so you only pay memory cost for the texture detail near you.
Data is streamed from the disc as needed, so you can have very large terrains without exceeding your memory. Both geometry and texture data are loaded on the fly.
What is rendered is what is collided against, so you get full interaction support for anything Atlas can render - overhangs, gaps, ditches, and so on.
As the toolset for this engine matures, it will be possible to actually create such terrains.
But the runtime as of now supports this sort of topology.
Atlas fully supports industry-standard DXT texture compression. It compresses offline for maximum quality, pregenerates mipmaps for minimal CPU usage at runtime, then streams it directly into GPU memory.
Creating Performant Terrain
The biggest factor to making performant, good looking terrains is to tune your data for the expected usage. The algorithm will deal well with almost any data set, but if you know how the landscape will be viewed, you can make some optimizations.
First, find the highest error metric that looks good. Pay attention to the polygon usage report from the chunk generator. You might need to up your error metric, or make the chunk quadtree deeper.
For texture quad trees, you need to find balance between depth of the tree and size of the textures. Larger textures will load more quickly, but may cause hitching when they upload. Smaller textures will load more smoothly but potentially take longer to detail in. Similarly, shallow trees load faster and take less memory. (The parent levels of a texture remain resident in memory while the child textures are loaded.) But deeper trees allow you to have more detail without having to increase your texture size. Node texture sizes over about 1024x1024 may run less well on older cards.
If you know that you're going to be up close to the terrain and moving relatively slowly (ie, an FPS), you can have a deeper, more detailed geometry data set. On the other hand, this is a waste for a flightsim - you can spend more resources on high texture detail, and cut back significantly on geometric detail.
Also be aware that the terrain collides exactly against whatever is rendered for the lowest level detail. Having too many polygons in a single chunk at the lowest level may cause some performance issues.
Now that you have an idea of what the Atlas terrain system is capable of, it's time to move on to the technical details.
Continue on to the next lesson, Generating Atlas Data.