About the Material System in the game

Material, the word has its own interpretation from all walks of life.

The artist collectively referred to object textures, object colors, and highlights as materials. The graphic interfaces such as d3d and OpenGL call the object surface texture as texture, while the diffuse reflection and highlights are called materials.

 

The materials mentioned in the game engine or graphics engine are different. The materials mentioned in the engine are not only the above content. The so-called material in the engine refers to a series of state control during rendering of objects. For example, the Alpha mixing switch, Alpha mixing factor, texture overtaking mode, texture channel status, texture matrix, and cropping mode are controlled by setrenderstate, settexturestagestate, and setsamplerstatestate in d3d. In OpenGL, most of them are controlled by glenable.

 

The material system we mentioned is based on this. The factors mentioned above constitute our material. It is also the status control value that we submit to the device when rendering an object. A single rendering of an object is called a pass. So we naturally name the smallest unit of Material Control during rendering as pass, then:

 

Struct texturestate

{

Void * texture;

Int colodrop;

Int coloragr1;

Int coloragr2;

Int alphaop;

Int alphaagr1;

Int alphaagr2;

... // More content

};

 

Class CPASs

{

Ccolor mambient;

Ccolor mdiffuse;

More information

 

Bool malphaenable;

Int mscrblend;

Int mdstblend;

Int mcullmode;

Texturestate [4] mtexturestates;

... More

};

 

When rendering an object, you only need to apply the state in this class to the device to complete the rendering of the object.

 

This is the basic content of the Material System, which is also the easiest thing to do.

However, we all know that every time a graphic interface such as d3d or OpenGL is set to a GPU state, there will be a certain amount of overhead (you can see the specific overhead values of some functions through viewing the relevant documentation ). To ensure smooth rendering, we have to reduce the overhead.

 

Naturally, we will think of minimizing switching. But how can we reduce switching. We can record the status of our hardware. When setting the next one, we can first determine whether the current hardware status is the same, if the current status is the same. You do not need to set it again. Although some graphic interfaces provide similar functions at the bottom of their layers. However, we can't judge it externally. In d3d, external judgment is more efficient than internal judgment. Note that we make the same judgment in our own program. Therefore, when another program modifies the device status, it will produce unexpected results. Therefore, we should properly query the device status and update our own status record table. The query interval should be tested based on your actual situation.

 

 

It is not obvious to Improve the efficiency by recording the State. Therefore, we need to sort the materials. As for how to sort the materials, this algorithm will not be explained here. In short, we will arrange similar materials together. Because the materials are very similar, switching is reduced when the next image is painted, which greatly improves the efficiency.

 

Now that the device is involved, we have to consider the device issue. What if the device does not support the current material status? Returns false without rendering. Or let the program go down? For some important performances, it is the best practice for devices not to allow programs to go down. However, if the channels such as texture mixing are insufficient, it is impossible to let them go down. After all, the game program we designed is intended for more players to play, isn't it? This will involve the pass splitting issue.

 

Ogre has done a good job in splitting pass data. Based on the user's device performance, if not, it will be split until the user is satisfied, and finally let an object be rendered multiple times to achieve the mixed effect of multiple texture channels. While multi-pass is a place that must be considered during rendering. After all, some special effects must be implemented using multi-pass.

 

For the multi-pass design, we can refer to the ogre material method or d3dx effect framework. We call the final effect solution a rendering technology technique, and one technology can be completed by multiple passes.

 

Class Technique

{

... More

Vector <CPASs *> mpasses;

};

 

This satisfies our needs. For the same effect, we can provide a variety of technique options for the program. The selection can be based on hardware performance or the configurations manually selected by the player.

The final structure is as follows:

Class cmaterial

{

Public:

... More

Vector <ctechnique *> mrendertechs

};

 

 

 

Let's talk about it in a mess. I hope I don't feel dizzy !!!