Search the Community

What impact does the particle system have on the CPU? In the UWA particle module report, the following parameters need our attention: “ParticleSystem.Update”: The average CPU time for particle system update; “ParticleSystem.Draw”: The average CPU time for the particle system to submit Draw Call per frame; “ParticleSystem.ScheduleGeometryJobs”: This function is related to the scheduling of multi-threaded update tasks of the particle system. Generally speaking, the larger the value, the more the number of particle systems playing in the project. According to UWA’s experience, generally speaking, the main influencing factors are as follows: Number of Particle Systems In the UWA performance briefing, directly search (ctrl+F) “Number of particle systems”, two test results will appear: (1) UWA recommends no more than 600 for the number of particle systems (Device model with 1G). This number refers to the total number of all ParticleSystems in the memory, including those that are being played and those that are in the buffer pool. (2) The number of particle systems for Playing, here refers to the number of ParticleSystem components that are being played. This includes both on-screen and off-screen. We recommend that the peak number that appears in one frame does not exceed 50 (Device model with 1G). So how to check which particle systems are cached during the running of my project? Are these Playing particle systems reasonable? Here is a trick, which can be viewed in the report’s Specific Resource Information – Particle System. As shown in the figure above, the blue line represents the particle systems that are all loaded into the memory, the purple is suspected to be redundant, and the yellow is the number of particle systems that are actually played. Following the life cycle diagram of the game running, you can choose the screenshot of a certain frame, especially the part with a higher number, and then turn on the [Selected Frame] mode to view all the ParticleSystems and all the ParticleSystems Playing under this frame. In view of the above two problems, the optimization and analysis can also focus on these two points: (1) Pay attention to whether the peak of the number of particle systems (the blue curve) is too high. You can select a peak frame to check which particle systems are buffering, whether they are all reasonable, and whether there is excessive buffering; (2) Pay attention to whether the peak value of the number of particle systems Playing (the yellow curve) is too high. You can select a peak frame to check which particle systems are playing, whether they are all reasonable, and whether you can make some production optimizations (see below for details). About ParticleSystem.Prewarm We can notice that there is a function in the important performance parameters of UWA report: ParticleSystem.Prewarm, which means that there is a particle system in the current frame with the “Prewarm” option turned on, and the particle system with this option turned on is instantiated in the scene, or when it is converted from Deactive to active, a complete simulation will be executed immediately. Take “flame” as an example: when Prewarm is turned on, you can see the “big fire” in the first frame after loading, instead of starting from the “small spark” to gradually increase. However, the operation of Prewarm usually takes a certain amount of time. It is recommended to turn it off when it is not used. What impact does the particle system have on the GPU? If the particle system has a serious issue, it will also affect the performance of the GPU. We can use the Overdraw data in the UWA’s Real Device Testing report to locate the issue. Generally, we recommend that it should not exceed 5 on low-end and mid-range devices. Combining the trend chart of Overdraw and the corresponding screenshots of the game, we can check whether the particle special effects are too large or overlapped. Here are some common optimization ideas: For low-end devices, reduce the complexity of the particle system and screen coverage as much as possible, thereby reducing its rendering overhead and improving the running smoothness. The specific approach is as follows: (1) Reduce the number of particles and the number of particles on the same screen on the low-end and mid-range devices, such as displaying only “critical” particle effects or particle effects released by their own characters, so as to reduce the CPU overhead of Update; (2) Close the particle system that is far away from the current field of view or the current camera, and turn it on after getting close, so as to avoid unnecessary overhead of particle system Update; (3) Minimize the coverage area of particle effects on the screen as much as possible. The larger the coverage area and the more stacking numbers, the greater the rendering overhead. Original post: https://blog.en.uwa4d.com/2022/01/18/unity-performance-optimization-animation-module/