Brief analysis of the implementation principle of ogre rendering Queue (1)

Rendering queue is an important concept in ogre. All objects in the scenario are put into a specific rendering queue by ogre before being drawn. The rendering queue mainly plays two roles: 1. ensure the correct order of drawing. For example, first draw the sky box, then draw the general object, and finally draw the interface. 2. Improve rendering efficiency. Ogre puts objects with the same pass together for rendering, so as to minimize the switching of rendering status. Generally, users usually set the rendering queue serial number in entity. In fact, the entireThe workflow of the rendering queue is far more complex than this, But it basically does not require end user intervention. This articleArticleIt is necessary to analyze the details of this part without intervention.

The rendering queue is a key part of the Ogre rendering process and control the rendering efficiency. Therefore, you should thoroughly learn and understand this part. I think that through this process, we can not only learn the design ideas of excellent open-source libraries, but also understand the implementation principles to help us better use them. In addition, there are many key classes associated with the entire ogre rendering process. Understanding the rendering queue is of great benefit to further understanding other functions.

 

In order to better understand this content, I plan to expand it in the following order, hoping to make it easy to understand.

1.Rendering queue implementation.

This section mainly analyzes the relationship and implementation details between various classes in the rendering queue in ogre,

2. OgreAnd how to interact with the rendering queue.

This section mainly analyzes who will operate the rendering queue when. This part helps to gain a deep understanding of how the various parts of the rendering queue collaborate to complete the entire work.

3.What can users do.

This section mainly analyzes the operational space left by the rendering queue.

 

Implementation of rendering queue

It is a simple relational diagram of the main classes corresponding to the rendering queue and serves as a reference diagram for reading subsequent content.

 

 

You need to know that the class that the rendering queue first comes into use is renderqueue. At first glance, it is easy to misunderstand the name. In fact, renderqueue is not a rendering queue but a manager, manages a group of objects named renderqueuegroup. Renderqueue is a scenario Manager (scenemanager) object. A scenario manager has a renderqueue object.

 

RenderqueuegroupIndicates a rendering queue group with a fixed number. Obviously, this class is not the final rendering queue, but also a manager that manages a group of renderprioritygroup objects with priority. The fixed number of renderqueuegroup is defined by the renderqueuegroupid enumeration variable in ogre, as follows:

Enum Renderqueuegroupid

{

Render_queue_background= 0,

Render_queue_skies_early= 5,

Render_queue_main= 50,

Render_queue_skies_late= 95,

Render_queue_overlay= 100,

};

EveryThe rendering queue group object has a value in the preceding enumerated variable to identify the processing priority of the rendering queue group. From the enumerated values, the smaller the number, the more draw first. For example, the sky queue group numbered 5 should be drawn before the interface numbered 100 overlay the queue group.

RenderqueueThis class stores each renderqueuegroup object as an index based on the fixed number of the rendering queue group. Renderqueue does not provide a method to create the renderqueuegroup object. You only need to provide a number to obtain a queue group object. The corresponding object is automatically created based on the existence of the specified number, and the rendering queue group of each number is only one. The renderqueue class uses a map with a fixed number as the key to save the rendering queue group objects. The advantage of this is that the rendering queue group objects can be quickly inserted and obtained. Because map is automatically sorted during insertion, rendering queue group objects can be retrieved from the map in sequence during painting, instead of processing the sorting separately.

RenderqueuegroupThe implementation of this manager is relatively simple and provides something called a priority number. Each priority number corresponds to a renderprioritygroup object. In fact, this layer of priority is to provide more precise priority based on the above grouping. For example, in the sky box rendering object group numbered 1, you can divide several priorities. This priority is not required in most cases. You can use the default value.

Let's take a look at the renderprioritygroup object managed by renderqueuegroup. In fact, this is not the final rendering queue, but also a manager, which manages six fixed types of rendering queues. The layer-by-layer structure is used to determine the position of the rendering queue. The rendering queue in which the rendering object is finally put is the responsibility of the renderprioritygroup object. The classification criteria are determined based on the technique information associated with the rendering object. Generally, the rendering queue of the rendering object is determined based on whether to use transparent materials or whether to enable shadow. The specificAlgorithmI will not explain it in detail here.

RenderprioritygroupThe objects managed in objects are the queuedrenderablecollection class, which is a real rendering queue and stores and sorts rendering objects. Currently, the rendering queue supports three sorting methods: ascending, descending, and pass. The sorting method must be determined when the rendering queue is empty. Because the elements inserted into the rendering queue depend on the sorting method, the sorting method cannot be modified when the set is not empty. The rendering queue class contains two sets used to save rendering objects, as shown below:

Passgrouprenderablemap Mgrouped;

Renderablepasslist Msorteddescending;

The first set stores the set sorted by pass. Any rendering object drawn using the same pass object is placed in this group.

The second set is the set that sorts rendering objects by the distance between the rendering object and the camera. In fact, this set is used for both ascending and descending order, and reverse access can be used to achieve reverse results.

From the source code, we can see that when inserting a rendering object, the rendering object is placed into the set described above according to the sorting method set by the current rendering queue. It should be noted that when an element is inserted, it is only stored in a group but not really sorted. The timing of sorting will be analyzed later. The rendering queue has the sort method to complete this sorting.

 

Now let's look back at how the entire rendering queue achieves the design goal of ensuring correct drawing order and improving drawing efficiency.

First, let's look at the draw sequence. The renderqueuegroup object with a fixed number is the first step to ensure the order of drawing. It splits the background, objects, and interfaces to ensure that the rendering sequence is normal. In addition, the rendering queue queuedrenderablecollection objects can be arranged in ascending or descending order of distance to ensure that objects with transparent attributes are drawn from the far and near order, and the second step to ensure the order of painting is completed.

Then we can see the rendering efficiency. The rendering queue queuedrenderablecollection objects can be grouped by pass. Rendering objects drawn using the same pass during painting are continuously drawn, greatly reducing the switching of rendering status.

So far, we have analyzed the implementation principle of the rendering queue function. The system is divided into four layers to implement the entire rendering queue function. The first three layers play the role of the manager, and the last layer stores the rendering objects. The organizational structure is complicated. I think this complex software structure can be understood more easily only through the application context, so next we will analyze how other classes in ogre interact with the rendering queue. The second part of this article will analyze the interaction part.