Make full use of programmable GPUs in the game

InArticleBefore I begin, I sincerely apologize to my dearest mibao for using this garden. I remember my serious mistakes and used this as a training. All my friends testify that I will self-respect myself and change my mistakes. I am fully aware that the massive GPU throughput and powerful floating point computing capabilities will be greatly improved.ProgramPerformance can also make full use of the value of the video card. GPU, as one of the two programmable high-performance chips on the computer, has not been valued by common programmers for a long time, mainly because of its programming troubles, lack of data tools. Here I will describe as much experience as possible in using GPU to do things in my game programming, mainly to express an idea of rational use of computer resources.

I am not familiar with dx10 and sm3.0, so more useful gs data output and even more powerful Cuda are not covered in this article. Here we will discuss more about sm2.0 and DX9, I believe most of my friends should be qualified for practice. Professional gpgpu uses scientific computing as an example. I don't think it's okay. Here I will talk about how to put all the geometric computing on the bulletin board into the GPU.

The bulletin board is no longer familiar to graphic programmers. It is to make the ry (usually a quadrilateral) always face the camera. In fact, it is a rotating process. The simplest thing is snow, grass, and so on, here I want to explain an example of a slightly complex point, such as the chain magic in Warcraft or the fragtal lightning in the sky, in fact, these are links to one or more pieces of ry between two points. A segment may be a quadrilateral or multiple quadrilateral, for example:

 

If a segment is not a patch, you don't need to rotate it, so we mainly talk about the above situation. The mage sends a link magic to one or more targets. In fact, it generates a link between the targets and carries out texture animation on the patches, perform operations such as geometric transformation when the orientation of the target is constantly changing. The principle is very simple, that is, to make all the patches face the audience, so that there will be no serious distortion during watching in a specific direction, we mainly look at how to put all the computing into the GPU.

 

First, we must generate all required vertices in the CPU, Because GPUs without GS cannot generate vertices. For example, if we want to generate a geometric bar from point A to point B, we will generate eight intermediate points with 10 points in total. Through the adjacent two points, we can find the center point of the two points, pmid = (PI + 1)/2, we generate four vertices for the first segment, because the subsequent segments share the last two vertices of the previous segment, only two vertices are required for each segment. The geometric coordinates of each vertex are set to the coordinate pmid of the intermediate point in this segment, in this way, the vertices of each segment are nest together. We need to expand them into a quadrilateral in Vs, but we need information about how to expand the current vertex, such:
 

We can use UV coordinates for identification. All UV coordinate Y components with 0 are backward extended, and Y components! All values of = 0 are extended forward, while X = 0 is left, and X = 1 is right. Because the textures on the chain are u-directed to clamp and V-directed to wrap, UV just gives us how to expand the information of the ry, but how much? We need to use a data stream to send information, so we can use texcoord1. The number of extensions in the X and Y directions is exactly two float requests. The rotation is followed by expansion. We need two axes, one in the X direction and the other in the Y direction. The other in the Y direction is actually leashy = PI + 1-Pi, the principle is that the announcement board is rotated, but the axes are different. leashx = cross (leashy, (camerapos-vertexpos) in the X direction), so we need a stream to be sent to leashy, leashx can be calculated by the original vertex coordinates and leashy in Vs, instead of in the CPU. So the only thing that needs to be done in the CPU is to generate the vertex and UV, and the calculation of these two computations is very small. The calculation of the actual coordinate of the vertex and the rotation of the announcement board are all put in. Now let's see what vs looks like.

Float3 g_camerapos;
Float4x4 g_worldmatrix;
Float4x4 g_viewprojmatrix;

Struct vs_input
{
Float3 vertexpos: position0;
Float2 uv0: texcoord0;
Float3 leashy: texcoord1;
Float2 size: texcoord2;
};

Struct vs_output
{
Float3 projpos: position0;
Float2 uv0: texcoord0;

};

Vs_output vs_main (vs_input in)
{
Vs_output out;
Float4 vertexworldpos = MUL (float4 (in. vertexpos, 1.f), g_worldmatrix );
Float3x3 worldrotatematrix;
Worldrotatematrix [0] = float3 (g_worldmatrix [0] [0], g_worldmatrix [0] [1], g_worldmatrix [0] [2]);
Worldrotatematrix [1] = float3 (g_worldmatrix [1] [0], g_worldmatrix [1] [1], g_worldmatrix [1] [2]);
Worldrotatematrix [2] = float3 (g_worldmatrix [2] [0], g_worldmatrix [2] [1], g_worldmatrix [2] [2]);
// Note that the rotation axis must be rotated. Otherwise, the rotation is incorrect.
Float3 rotatedleashy = normalize (MUL (in. leashy, worldrotatematrix ));
Float3 leashx = normalize (g_CameraPos-VertexWorldPos, rotatedleashy ));
// Start rotating
Float3 dealedpos = float3 (0, 0 );
Float3 extendy = in. Size. y * rotatedleashy;
Float3 extendx = in. Size. x * leashx;
If (in. uv0.y = 0)
{
If (in. uv0.x = 0)
{
Dealedpos =-extendy-extendx;
} Else {
Dealedpos =-extendy + extendx;
}
} Else {
If (in. uv0.x = 0)
{
Dealedpos = extendy-extendx;
} Else {
Dealedpos = extendy + extendx;
}
}
Out. projpos = MUL (float4 (vertexworldpos. xyz + dealedpos, 1.0f), g_viewprojmatrix );
Out. uv0 = in. uv0;

}

How is it? The CPU does not need to calculate vertex coordinates, nor to rotate the announcement board. After some improvements, it can even complete the stretching and deformation of the chain without the need of CPU management. Before the advent of programmable GPUs, many computing tasks were completed in the CPU. Now, both sm2.0 and sm3.0 can be transplanted to the GPU.

Sorry again!