-Some Ogre rendering experiences

Efficiency is an inevitable topic for commercial online games. In order to leave more space for the client logic, the rendering module should be as efficient as possible. let's just talk about the rendering Optimization of Ogre. Take the familiar tianlong Babu as an example. according to the tianlong code circulating on the Internet, the rendering of the Ogre and CEGUI sections has serious performance problems. Ogre: Implementation of terrain, one tile, only Batch Optimization by material, the camera is not cropped based on materials. As a result, many static entities are added to the game in batches from the game perspective, which is totally wrong. Like the terrain, only the batch is optimized and no camera cropping is performed. CEGUI, for example, a normal font can be cached as an image. The best way is to port the image to 0.75, which improves the efficiency by N times. cegui I am too lazy to talk about, just talk about the optimization of the Ogre part.

 

Before optimization, first understand the optimization principle.

1). Renderable and rendering batches:

What is the rendering batch of Shenma? Let's take a look at the tutorial. In short, it greatly affects the rendering efficiency, so there are as few rendering batches as possible. for example, rendering 10000 triangles in 10 batches is much faster than rendering 10 triangles in 10000 batches,

How is a batch counted? Rendering an Renderable is a batch. Renderable is the smallest rendering unit in Ogre, and all objects to be rendered inherit from this.

One sentence: A renderable is equal to a batching (rendering batch), reducing the renerable in the scenario reduces the batch.

How to Reduce renderable? For example, if there are two trees with the same material (two renderable trees), I can synthesize one tree (one renderable). There are two synthesis methods. One is static merge by the artist in max, one is StaticGeometry)

It is worth mentioning that a mesh is not necessarily a batch, but a submesh is. If a mesh has two submesh of different materials, it is normal,

If there are two submesh with the same material, it is not good. I should immediately seek an artist and scold him. Why not combine two submesh with the same material?

2) MovableObject and camera Cropping

Ogre's OctreeSceneManager camera cropping is based on the surrounding box, so it means that objects with the surrounding box can be cropped. Does Renderable have a surrounding combination? No! But MovableObject is available. MovableObject is the basic object for moving objects. It inherits ShadowCaster and can cast shadows.

It is worth mentioning that the camera's cropping is not in the unit of MovableObject, but in the unit of SceneNode. Only the MovableObject mounted to the SceneNode can be used.

Will be cropped,

3) To render, Renderable, move, Moveable, and if all are required, the simplest object should be SimpleRenderable: public MovableObject, public Renderable

Think of the previous use of mesh for terrain, very stupid, not efficient, should be mesh class too large, contains too many things don't need, use SimpleRenderable is the highest efficiency.

 

One way to achieve terrain is to use a grid. Each grid has a quadrilateral, which does not share vertices and does not support the level of detail. However, a grid can have multiple layers of texture, which is suitable for 2.5D angle-of-view games, such as Warcraft 3 and tianlong

The other is the mainstream 3D Game practices, sharing vertices and dles. The disadvantage is that the texture layers of a terrain page are as many as those of the previous terrain... for example, eight layers are enough, and texture transition is quite natural. the texture transition of the grid fight is always ugly.

1) The terrain implementation principle of tianlong is as follows.

The entire terrain is composed of multiple tile, class TerrainTile: public Ogre: MovableObject

A tile is a MovableObject used for camera cropping.

Each tile contains a RenderableList. In a tile, the lattice of the same material will be made into a Renderable,

Tile is 32, so there are 32*32 grids. If these grids use 10 different materials, These grids will be made into 10 Renderable

Rendering is no problem. rendering by material in batches, 10 in batches,

But there is a problem with camera cropping. The camera can only crop by tile, because tile is MovableObject, but the 10 Renderable cannot be cropped separately.

In this case, for example, if the camera only sees one of the most edge grids in the tile.32 * 32 lattice, it will also render the entire tile, with 10 batches ....

If you make all 10 Renderable into MovableObject, You can crop it. If you only see this grid on the edge, only the Renderable on the edge will be rendered, one batch.

Practice has proved that for a 2.5D game, the number of terrain games can be reduced by almost half.

2) tile size

How big is tile, and the most efficient? This is related to the camera. It is best to have a game perspective. The camera looks a little larger than that. tianlong's 32 is reasonable for his perspective.

3) texture atlas

Tianlong's surface texture is very small, 128*256 leads to a lot of materials and a lot of batches. If texture atlas is used to synthesize small textures into large textures, the number of batches will be much reduced, however, there will also be other additional problems, such as the gaps caused by mipmap, to solve the gaps. There are actually many solutions abroad, such as writing shader and adjusting texture coordinates under different mipmaps, or reserve the texture coordinates and add a circle of pixels with the same edge on the existing texture, so that no other texture pixels will be obtained, resulting in a gap.

Tianlong 2 adds the sky perspective. Even if many scenes are seen, rendering efficiency is not greatly affected. Therefore, I personally think that he should make texture atlas to reduce the number of batches of the entire scenario, otherwise, the sky perspective cannot be realized.

 

Reprinted statement, transferred from: http://blog.csdn.net/pizi0475/article/details/6315834