Special effects optimization and other ogre Optimization

0. Order

For ogre games created using the particle universe, the efficiency of special effects is very serious. I haven't published any articles for a long time. Here I will share some of my problems and my personal solutions with my recent problems.

1. Introduction, about the visual particle quota of the particle unverse

Pu comes with this parameter, which is intended to limit the number of visible particles to facilitate processing of cyclic particles in the particle pool, avoiding excessive creation and deletion operations. Although this parameter is provided in the special effect editor for Pu in actual use, it is not emphasized with the art production personnel in advance, therefore, they did not pay much attention to this parameter during the production process, and always used the default Pu value of 500 (this is too much ..). When there is a real efficiency problem, I specifically tested it. For the announcement board particle system, the quota setting is too large, because the ogre has its own BB pool, too much memory will only be occupied. However, for the Renderer such as entity supported by PU, if the quota settings are too large, too many scenenode will be created, seriously affecting the performance.

According to the scenenode mechanism, ogre controls the addition of objects to be rendered to the rendering queue. Too many scenenode will first perform redundant Scenario Management pruning, regardless of whether the movableobject of the attach is visible, the receiveshadow function will be called after the addrenderqueue. The entire process is also very slow. You can create one entity for each of the 500 scenenode nodes in the sample. Even if only one frame is rendered, the speed will be very low, for this reason.

Of course, this is not a matter of PU, nor can it be regarded as optimization. It is just a simple discussion of the importance and general principles of this parameter. My specific practice is to directly eliminate this parameter, but to dynamically set the quota according to the number of particles when creating the Pu system, simply remove this parameter in the editor. After this modification, check the efficiency of some previous particle systems using ribbontrail and entity, and greatly improve them.

2. True optimization: update and cropping of Pu

After scene rendering, all pu effects are loaded and each frame is updated logically. In fact, most of the effects we don't see are not updated. When the Ogre removes the scene nodes attached to the invisible Pu From the rendering queue, the update of the PU should be paused. However, the Controller of ogre is used by default in the Pu, all of which are force update per frame. Therefore, the Pu update should be notified only when the inner addrenderqueue of Scenario Management is used. After doing so, we can reduce the number of logical updates and the corresponding CPU bound in a large scale, and the frame speed is greatly improved after testing.

3. PU external enclosure settings

Each particle effect may contain many special effect elements, such as flame and halo. With the particle emission, the surrounding box changes dynamically, and the Pu is also updated with the surrounding box. On the one hand, it is not necessary to frequently repeat the computation of the box surrounded by the particle system; on the other hand, the actual box of the particle system may be much larger than the box of the expected effect (for example, the halo may be very large, but in fact people are concerned with a little flame in the middle ), cropping is affected. Therefore, the method I use is to use a specified external box, which can be a default value of moderate size or can be manually set by art as needed.

4. Try to merge the Pu system as the sub-technique.

Every system in PU is a movableobject. In some cases, all systems that we create are independent because of special requirements. Each system corresponds to a technique. If the system that can be merged is merged into technique, the efficiency can also be improved.

5. Return to the scenario node.

From the perspective of PU, in many scenarios of a game project, some objects can belong to the same category, and they are characterized by co-display and co-hiding. For example, replace the sub-nodes of a character, for example, each special effect element in a special effect (not only pu, but also another element ). However, it may be for better engine management, or for the purpose of using the hierarchical ry mechanism of scene nodes. The objects originally supposed to be hidden and displayed together are divided into N scenenode. Of course, too many scenenode are involved in ogre scenario management. For ocree, for example, if the node is partially encrypted, it will inevitably lead to efficiency loss. But in fact this is completely unnecessary, because in this case, we only need to let the Ogre calculate a scenenode crop. If this node should be included in the rendering queue, all its nodes should be included at the same time. This cannot be completely a problem of the Ogre itself, but the abuse of scenenode (which is not fully understood by its internal mechanism) has indeed caused such performance loss. For an engine that has been formed, it is very difficult to change the use of scenenode. In practice, I changed the code of octreescenemanager and added a special scenenode similar to finalparent, set a tag (I use setuserany) where this optimization is needed. After the settings are complete, all the child nodes derived from this node are finalson. If you encounter a node such as finalparent during the actual octotree or other scenario cropping process, you can directly determine whether to crop the node. If you do not crop the node, insert all the movbleobjects of all its subnodes into the rendering queue. If you encounter a finalson node, You can reject it all. Of course, the implementation method is benevolent and wise. I am doing this to avoid modifying the ogremain code.

6. banba

In fact, in most cases, the databases we use are the wisdom of the database designers and the result of careful testing. If there are some major efficiency problems, most of the time the user does not correctly understand the database or simply is caused by improper use. In the case of performance problems, the first thing is not to scold the library for poor efficiency, but to think about whether the entire process we use is unreasonable by analyzing the source code of the Library (if any. For example, scenenode abuse of ogre is a typical example. Of course we can optimize it, but isn't the cool code better?

Of course, it is undeniable that even a third-party library such as ogre has many unreasonable designs. For example, he uses his controller to control UV animation and sequence frames, this is a very flexible and commendable design, but the ogre is also updated on every frame. If UV and sequence frames are used in a specific scenario, and all updates are considered as a loss of performance. It is also well known that the rendering queue is too cumbersome and there are no shortcomings such as effective batch merging. Of course, ogre is still an outstanding open-source work worth learning.