From an application process perspective, once the resources are loaded, an Entity can be created and attached to SceneNode. Next, look at SceneManager.

You have to say that the SceneManager class is really large. The light class SceneManager definition is nearly 3200 rows. The implementation also has 3800 lines. There is no desire to look at such a large class. Look directly at the class's comments.

/** 
    Manages the organisation and rendering of a 'scene': a collection of objects and potentially world geometry.

    This class defines the interface and the basic behaviour of a 
    'Scene Manager'. A SceneManager organises the culling and rendering of
    the scene, in conjunction with the RenderQueue. This class is designed 
    to be extended through subclassing in order to provide more specialised
    scene organisation structures for particular needs. The default 
    SceneManager culls based on a hierarchy of node bounding boxes, other
    implementations can use an octree (see OctreeSceneManager), a BSP
    tree (see BspSceneManager), and many other options. New SceneManager
    implementations can be added at runtime by plugins, see 
    SceneManagerEnumerator for the interfaces for adding new SceneManager
    types.

    There is a distinction between 'objects' (which subclass MovableObject, 
    and are movable, discrete objects in the world), and 'world geometry',
    which is large, generally static geometry. World geometry tends to 
    influence the SceneManager organisational structure (e.g. lots of indoor
    static geometry might result in a spatial tree structure) and as such
    world geometry is generally tied to a given SceneManager implementation,
    whilst MovableObject instances can be used with any SceneManager.
    Subclasses are free to define world geometry however they please.

    Multiple SceneManager instances can exist at one time, each one with 
    a distinct scene. Which SceneManager is used to render a scene is
    dependent on the Camera, which will always call back the SceneManager
    which created it to render the scene. 
*/

Direct google translation.

Manage the organization and rendering of "scenes": collections of objects and potential world geometries.

This class defines the interface and basic behavior of the Scene Manager. SceneManager works with RenderQueue to organize scene culling and rendering. This class is designed to be extended by subclasses to provide a more specialized organizational structure for scenes for specific needs. The default ceneManager eliminates based on the hierarchy of the node bounding box. Other implementations can use octree (see OctreeSceneManager), BSP tree (see BspSceneManager), and many other options. New SceneManager implementations can be added at runtime through plug-ins, and see SceneManager Enumerator for interfaces to add new SceneManager types.

There is a difference between "object" (which is a subclass of MovableObject and a movable discrete object in the world) and "world geometry", which is large and usually static. World geometry often affects the organization of SceneManager (For example, many indoor static geometries may result in a spatial tree structure), so world geometry is usually associated with a given SceneManager implementation, and MovableObject instances can be used with any SceneManager. Subclasses are free to define world geometry.

Multiple SceneManager instances can exist simultaneously, each with a different scene. Which SceneManager is used to render a scene depends on Camera, which always calls back the SceneManager that created it to render the scene.

Simply put, SceneManager manages scenes, eliminating objects and rendering through RenderQueue. This class only provides basic functionality, and more specialized functionality needs to be overloaded. Examples include OctreeSceneManager, BspSceneManager, and so on. These are all plugin s.

• BspSceneManager

Specialization of the SceneManager class handles indoor scenes based on BSP trees. This class improves the behavior of the default SceneManager to manage scenes where most of its geometries are organized into indoor environments organized by binary spatial partitioning (BSP) trees. BSP trees use planes as tree nodes to subdivide space step by step. At some point, we stop subdividing and everything in the remaining space is part of the "leaf" that contains many polygons. Usually, We traverse the tree to locate the leaf at a point in space (e.g. camera origin) and work from there. The second structure, the potential visible set, tells us which other leaves we can see from this leaf, and we test their bounding boxes on the camera cone to see what we need to draw. Leaves are also a good place to start collision detection because they divide levels into discrete areas for testing. And PVS technology is known for engines like Quake and Unreal. Ogre populates your world by calling BspSceneManager::setWorldGeometry to support loading Quake3-level files. Note that this interface is available at the top level of the ceneManager class, so you don't have to write code specifically for this class - just call Root::getSceneManager to pass ST_INTERIOR's SceneType, in the current implementation, you'll get BspSceneManager to silently disguise itself as a standard SceneManager.

• OctreeSceneManager

Common Octree Scene Management

• PCZSceneManager

Scene Manager that spatially divides scenes using Portal-Connected-Zones.

What each SceneManager does is not going deep. How should I use it? As described above, pass ST_when getSceneManager The ceneType of INTERIOR is obsolete and no longer used. Now you need to pass in TypeName through createSceneManager, such as "BspSceneManager".

 /// @deprecated typeMask is obsolete
        OGRE_DEPRECATED SceneManager* createSceneManager(uint16 typeMask,
            const String& instanceName = BLANKSTRING)
        { return createSceneManager(DefaultSceneManagerFactory::FACTORY_TYPE_NAME, instanceName); }

    SceneManager* Root::createSceneManager(const String& typeName,
        const String& instanceName)

SceneManager has also been used in previous studies, such as createEntity, createCamera, createLight, etc., to organize scenes through SceneNode.

SceenManager functions are mostly

• createXXX
• destroyXXX
• getXXX
• setXXX
• isXXX
• ...

Scenes include nodes, cameras, lights, entities, and so on. They look very large, but are easy to use.

Not every object in detail.

Scene management is as simple as that.