There are a lot of ogre managers.

There are so many managers in ogre, just like a bureaucratic company. There are only a few officers, and a bunch of managers are still Singleton. it is a Singleton, but a public constructor. when new is applied for 1st times, this is secretly assigned to the static member ms_singleton. When new is applied for 2nd times, assert will complain, of course, this is all done by the constructor of the template base class named Singleton (typical villain behavior, see it ). there are a lot of managers, and complicated things are also complicated.

1. logmanager
A. Global single logmanager combines the log pointer map set to control multiple log objects. One log object represents the input to a log file (the old one ).
B. At the same time, logmanager maintains the mdefaultlog object of the current default main event to show the function of the log object and hide the identity of the manager ).
C. Maintain the loglistener list of a monitor interface to perform the duties of being under external supervision as a manager (which is actually the responsibility for clearing the listener ).

2. dynlibmanager
A. the global single dynlibmanager combines the dynlib * pointer map set to control multiple dynlib objects. One dynlib represents the loading and unloading of dynamic libraries (typical bureaucracy, float, manager is required for all this ).

3. resourcegroupmanager
A. Global single resourcegroupmanager combination ResourceManager pointer map? Manager of the manager, rely on, good big official)
B. Install a trusted manager and set up a ResourceManager called General.

4. scenemanagerenumerator
A. Even it is a single system, an iterator, a little bit of ambition. If you don't want to talk about it, it can handle a bunch of scenemanager and it cannot afford it.
B. scenemanager (base class), which is unable to do anything at the beginning, is used as the default scenemanager. It is used for major and minor events, and is used as a first-hand indoor and outdoor package.

5. A bunch of middle-level cadres, a bunch of materialmanagers, meshmanager, participant systemmanager, skeletonmanager ......, all of them are Singleton, and some are still the door-stores of ResourceManager. They did two things at the beginning.
A. Name score: register with resourcegroupmanager to indicate that you are a manager of a certain aspect, _ registerresourcemanager.
B. Resource requirement: requests to resourcegroupmanager to control the parsing of a script _ registerscriptloader (that is, to divide resources ).
C. There is an overlaymanager, which is the best in archivemanager. There are several other factories under it to work for it. It is nothing more than being unable to do it, and pushing it to lower-level companies.

6. A bunch of plug-ins start to load. These plug-ins must be registered in the system.

7. The transparent object mtransparentobjects is sorted in Z order, and the opaque object is grouped by material.

8. I initially thought that materail was a very clever concept, and later I found that I was cheated. It managed the mtechniques array, while techniche managed the mpasses array (multipass render ), the final content is in the pass class, which expresses a rendering environment. because this bureaucratic system is too bureaucratic, it is unacceptable to render objects at a time (there are too many cross-Department Cooperation and each other). Rendering status switches frequently and the efficiency is extremely low, transparent rendering of disordered Z-order. therefore, you need to group by materail and sort by Z axis. The most important method of rendersystem accepts the renderoperation parameter.

9. pass and renderoperation are two of the most competent working people. They are controlled by people and the soul and core of the entire system, pass encapsulates the most important rendering state (that is, the state of the pipeline when gldrawxxx is performed, and the coloring system). renderoperation encapsulates the gldrawelements geometric rendering operation ), both form a complete rendering. that is, first, call setpass of scenemanager (in which it will still call rendersystem to set the pipeline status), and then call the _ render of rendersystem.

10. scenemanager's virtual method_findvisibleobjects is the core of Scenario Management. It groups renderable and sends transparent and opaque data to different rendering queues, renderable combines renderoperation and pass (but materail is used in the early stage), then scenemanager sorts, sorts, and sends it to rendersystem rendering.

11. scenemanager's _ renderscene is the core of basic rendering. It completes several tasks.
A. Frame Animation driver _ applysceneanimations
B. Scenario fig _ updatescenegraph
C. The rendering queue is updated. _ findvisibleobjects is used to update the main scenario. _ queueoverlaysforrendering is used to update the upper-layer main interface. _ queueskiesforrendering is used to update the sky box.

12. render queue renderqueue, maintain STD: Map <renderqueuegroupid, renderqueuegroup *> object, to express its internal multi-aspect (World, foreground, background) Rendering queue. renderqueuegroup is further divided into STD: Map <ushort, renderprioritygroup *, STD: less <ushort> to express the internal maintenance of the rendering queue by ushort priority (for example, foreground. renderprioritygroup maintains one mtransparentpasses and several solidrenderablepassmap instances.