Ogre 1.7 terrain System

Ogre 1.7 contains a new terrain component: ogreterrain component, which has the following functions:

1. Optional ogreterrain component and paging component independent of the scenario manager.
2. Editable terrain
3. Hierarchical geometry batching: the lower the level of detail, the fewer batch and vertex. At the lowest level of slice, the entire terrain page is a single batch, which is superior to the general fixed tiles terrain System for Large paging terrain.
4. Use skirts technology to handle terrain crack.
5. Built-in splatting layers support, configurable sampler inputs and pluggable material generators.
6. Supports global normal maps and light map generation in background threads
7. Built-in terrain loading and storage, including loading/processing in background threads
8. Real-time use of dump for camera settings (viewport sizes & dump bias)

When using paging component, ogreterrain does not fully comply with the paging component design.

1. Terrainpaging: Manages sectionfactory and terrainpagedworldsection, which are originally managed by pagemanager.
2. Terrainpagedworldsection: Manages gridstrategy and a terraingroup (instead of a group of pages)
3. Terraingroup: Responsible for Terrain loading and uses terrainslot. For Loading Code, refer to terraingroup: loadterrainimpl (terrainslot * slot, bool synchronous)
4. Grid2dpagestrategy: notifycamera> terrainpagedworldsection: loadpage> terraingroup: loadterrain> terraingroup: loadterrainimpl> terrain: terrain

Ogre 1.7 uses the new sample framwork, and sample framwork implements a simple game state management that allows you to switch between multiple scenarios.

Sample_terrain is loaded by samplebrowser as a plug-in.

 

Terrainlayersamplersemantic

/** Enumeration of types of data that can be read from textures that are
Specific to a given layer. Notice that global texture information
Such as shadows and terrain normals are not represented
Here because they are not a per-layer attribute, and Blending
Is stored in packed texture structures which are stored separately.
*/
Enum terrainlayersamplersemantic
{
/// Albedo color (diffuse reflectance color)
Tlss_albedo = 0,
/// Tangent-Space normal information from a detail texture
Tlss_normal = 1,
/// Height Information for the detail texture
Tlss_height = 2,
/// Specular Reflectance
Tlss_specular = 3
};

Terrainmaterialgenerator

Manage a group of profiles and a terrainlayerdeclaration by name (A terrainlayerdeclaration = a group of terrainlayersampler + A group of terrainlayersamplerelements)

Terrainmaterialgeneratora

Implement normal mapped and specular mapped terrain material. When terrain obtains the materla of terrain through terrain: getmaterial, it calls terrainmaterialgeneratora: sm2profile: generate to generate terrain material dynamically (for reference ). However, it is a terrain that uses a material, which does not meet my needs.

Terrain

The terrain of ogreterrain is separated into hierarchical tiles and rendered by hierarchical geometry batching.

Batching is also highly retriable, since you set a 'min batchsize' and 'max batchsize '. these 2 metrics determine how much the terrain is split up. A batch is any patch of triangles at a hierarchy level. the leaves of the quadtree that represents the hierarchy can range from the maximum batch size, to the minimum batch size at their lowest, and then after that 4 adjacent patches at the min batch count get grouped into one parent patch at the min batch size to drop the level of detail. so, a large difference between the min and Max batch size gives you more detailed levels at lowest level of the quad tree, so more flexibility in SLS picking (because each low-level patch can make its own SLS demo-when moving up the tree all 4 patches have to agree that it's time to drop the SLS it To happen ), but at the expense of less efficient batching. you can tweak the absolute and relative values of these batch sizes to get the balance you need between vertex count and batch count.

Terrain: Prepare (streamserialiser & Stream)

The loading and parsing of the terrain file. dat starts from terrain: Prepare (streamserialiser & stream) in the terraingroup: handlerequest call, and the data is loaded to system memory.

1. Use terrainglobaloptions to obtain global options.
2. Read the chunk marked by terrain_chunk_id from. dat. The read content is as follows:
   1. Terrain_chunk_id
      1. The alignment of the terrain (ogreterrain supports hanging terrain)
      2. Terrain size (along one edge) in vertices (terrain length and width, calculated by vertex)
      3. The world size of the terrain (World Coordinate Dimension of the terrain)
      4. Maximum batch size (along one edge) in vertices; must be 2 ^ n + 1 and <= 65 (maximum tile size, calculated by vertex)
      5. Minimum batch size (along one edge) in vertices; must be 2 ^ n + 1 (minimum tile size, calculated by vertex)
      6. The position of the center of the terrain (central point of the terrain)
      7. The height data (each height is 32bit)
   2. Terrainlayerdeclaration_chunk_id (samplers + elements + layers)
      1. Sampler number (sampler that will be used with each layer)
      2. Read all samplers, and each sampler is saved in terrainlayersampler_chunk.
         1. Terrainlayersampler_chunk_id
            1. Sampler descriptive name that is merely used to assist in Recognition
            2. The format required of this texture
      3. Number of elements (sampler that will be used with each layer)
      4. Read all elements, and each elements is saved in terrainlayersamplerelement_chunk.
         1. Terrainlayersamplerelement_chunk_id
            1. The source sampler index of this element
            2. The Semantic this element represents
            3. The color element at which this element starts
            4. The number of color elements this semantic uses (usually standard per semantic)
      5. Read all layers, and each layers is saved in terrainlayerinstance_chunk.
         1. Terrainlayerinstance_chunk_id
            1. The world size of the texture to be applied in this layer
            2. List of texture names
      6. Packed layer blend data
         1. Size of the blend maps for a terrain
         2. Read all blendmaps and put them to mcpublendmapstorage.
      7. Derived Data
         1. Terrainderiveddata_chunk_id
            1. Normalmap
            2. Lightmap
            3. Colourmap
            4. Compositemap
   3. After reading the terrain data, construct the entire quadtree.

Each terrainquadtreenode in the quadtree has a scenenode, movableobject, and renderable. The result is a quadtree tree and a screennode tree. The quadtree nodes are all terrainquadtreenode. The depth of the screennode tree is 2. A terrain with a single side of 513 will obtain two trees. Quadtree is created in terraingroup: handlerequest call terrain: Prepare, while the screennode tree calls terrainquadtreenode: Load in terraingroup: handlerequest.

1.  
   1. Terrain: distributevertexdata: Based on the ogreterrain's dashboard algorithm, find the terrainquadtreenode with vertex, call assignvertexdata, and create the buffer zone vertexdatarecord. Vertexdatarecord contains vertex data and index data.

Chunked (http://tulrich.com/geekstuff/sig-notes.pdf)

I have seen too many terrain rendering algorithms in my eyes, but I finally found that what I forgot in my mind will always be used now. To master and transform ogreterrain, go to http://tulrich.com/geekstuff/sig-notes.htm to review chunked dles.

 

Refer:

New Terrain early shots

Finally, ogre began to improve its support for terrain rendering.

Paging as a core feature-Design Notes

Chunked (http://tulrich.com/geekstuff/sig-notes.pdf)

Building ogre trunk (1.7)

Building cegui

PCRE for Windows (win32)

Blend maps: enhanced terrain texturing