GPU and Particle

The cause is: a long time ago, my former employee left behind a complete particle system, and the boss was not satisfied, so he had to ask someone to write it again.
First, let's talk about the particle system of our colleagues: A general particle system, a transmitter, a filter, a Renderer, and a particle pool. It takes into account both 2D and 3D particles, art can be used to complete most of the results, and the results are cool! Very good particle system.
Furthermore, the boss is not satisfied: the efficiency is low, and the initialization of some particles is slow. Low Efficiency: on the one hand, it is because of the garbled art (repeatedly filling the screen in the same place in a large area), on the other hand, the CPU consumption is too high (mainly because the CPU resources reserved for the particle system are very few ). As this is a general particle system, it is difficult to optimize it. Complex mathematical computation is a part, and too many function calls are also a part.
Finally, the conclusion is: the general particle system is not used.
After determining the direction, start to think about the relationship between GPU and particles. Conclusion: When the CPU initializes the particle system, there can be surplus data and data can be duplicated, but it must comply with the GPU Data Processing Method: there is no data dependency between each particle; each vertex in the particle has no data dependency. The complete life process of a particle only depends on the initial data, and even the particle does not need to reset the initialization data, the particle can be well drawn by obtaining the remainder of the life cycle. The multi-stream and instance technologies are used to greatly reduce the data that needs to be modified dynamically.
For example, in the general Particle System of a former colleague, when the rainwater is drawn, the motion track of the rainwater is calculated by GPU, in addition, the impact of random wind may be involved in the middle, so that particles cannot rely solely on initial data. Managing particle pools also consumes a considerable amount of CPU.
In the new rainwater particles, each rainwater is a vertical surface (composed of two triangles). Because of the Instance technology, there are only four vertices in the data stream describing the rainwater appearance, six indexes, all of which are placed in the GPU. Data describing the independent characteristics of each rainwater is stored in the second and third streams. Each rainwater occupies one vertex data. The second stream is placed with data that is not changed after initialization, data that may need to be modified repeatedly in the third stream. Therefore, all data is 4 * sizeof (vertex0) + 6 * sizeof (Word) + N * (sizeof (vertex1) + sizeof (vertex2 )). The data to be updated each time you draw is N * sizeof (vertex2 ). In the case of 2 k rain, about 32 K data needs to be modified. The data transmission speed is 2.1 Gbit/s in the 8x mode, and the 32 K * 60 (HZ) data is a trivial matter.
After the initialization of all data computing is complete, vs calculates the trajectory of each particle based on the system time. This involves the influence of a wind power-neither the wind nor the wind power is too serious, that is to say, the wind must be global. Although all the rain is skewed in one direction, it is quite cool. I set a fine-tuned mediation parameter so that the third stream does not have to be initialized repeatedly, and the rain still does not seem to have a sense of repetition.
In this way, a x fire sequence animation image is used to achieve a very realistic flame effect by combining texture animation and texture.