Chapter 7 Resource Management of book notes in Pro Ogre 3D Programming

Resource Group
A naming group can be loaded and detached as a whole. When loading, uninstalling, and initializing, all resources in the group are taken as an execution unit.
Instead of processing them one by one. Resource Group Management is purely for management convenience. Whether or not to use the group method has nothing to do with performance. False
If you add a resource location to the Resource Group Manager without specifying a group name, these resource locations are placed in the "General" group.
Resource Group and world ry
By default, ogre puts the loaded world ry into the "General" group. Override allows you to manage world ry like other resources. The unified scenario manager can provide clues about the total loading steps of the world, so that precise feedback information displayed on the progress bar can be provided during level loading.
Resource location)
The resource location is where ogre searches for resource indexes. Indexes indicate that all resources at a location are mapped by their names, which facilitates faster resource search. You can add or delete resource locations at any time of the program, without having to define what may be used in advance. The resource location in ogre is actually an archive, which means "a collection of Files ". The file system on the disk is
A type of archive. The other is zip archive. You can customize the archive format. This is done by rewriting the archive class. You must support enumeration of the named leaf files, wildcards, and node recursion to provide ogre with a stream to access the data of files in archive. Archive in ogre is read-only. The ogre Resource Manager uses the archive enumeration feature to index archive content. When ogre indexes archive, no resources are actually loaded.
Resource Lifecycle
There are four statuses of resources. The conversion relationships between statuses are as follows:

Undefined: the default status of all resources at the beginning of the program. Unless Declared, ogre knows nothing about the resources used by the program. After the code ResourceGroupManager: declareResource () is manually called or is parsed in the script, the resource status changes to Declared.
Declared: The Declaration tells the ogre to load some resources. ResourceGroupManager: declareResource () is always valid, including before the rendering system starts. This is different from ResourceManager: create () because the latter depends on the rendering system.
Unloaded: Call ResourceGroupManager: initialiseAllResourceGroup (), ResourceGroupManager ::
InitialiseResourceGroup (), or Root: initialise () (it will Initialize all declared resources before this call), the resource status enters Unloaded, the resource occupies a little memory to save its defined instance, but the resource itself has not been loaded into the memory. From another perspective (from Loaded to Unloaded), status changes may occur in the following calls: ResourceManager: unload (), ResourceManager: unloadAll (), ResourceManager: unloadAllUnreferencedResources (), resourceGroupManager: unloadResourceGroup (), or Resource: unload (). all these calls will still save the resource instance, but the real resource data will be detached from the memory.
Loaded: in this state, all data becomes valid. Invocation related to this status includes Resource: load (), Resource: reload (),
ResourceManager: load (), ResourceManager: reload (), ResourceManager: reloadAll (),
ResourceManager: reloadAllUnreferencedResources (), and ResourceGroupManager ::
LoadResourceGroup ().
Logical Resource Management
Resources are organized as named groups. Each group can contain any type of resources. Each resource has its own resource manager, which is responsible for loading and detaching specific types of resources. Ogre does not implement a specific memory management solution for its resources. If you need to manage a certain resource based on the "least recently used algorithm" solution, you need your own code. It is worth mentioning that most of the current video card drivers have implemented the LRU algorithm management for most important resources.
Resource Loading
If there is no pre-load, the resource will be loaded when it is accessed. The actual loading and unloading are the responsibility of the resource.
Manually load Resources
The resource management layer is not responsible for actual loading and unloading. Generally, you do not have to worry about whether resources exist in the volatile media. However, you need to consider the manual method. The manual resource loader must be ready to reload resources at any time. If a resource is generated by a program, the manual resource loader must buffer the resources in the memory or recreate the resource when the resource management is loaded. Ogre considers that manual loading is no different from automatic loading.
Background Resource Management
By default, ogre is NOT thread-safe. If # define OGRE_THREAD_SUPPORT 1 in OgreConfig. h
The thread synchronization function of the Code becomes effective. In addition to the thread containing the Root instance, we can enable new threads to operate on the resource management class and methods to implement flexible resource loading solutions.
Non-Background Resource Management
The Observer mode is widely used in Ogre, and the resource management system is no exception. The ResourceGroupListene callback Interface contains several methods.
Allows fine-grained monitoring of resource loading.
Detach a resource
Resources are always stored in the memory after being loaded until they are forcibly uninstalled by the application (either through the resource group manager or directly released by the resource ). Resource Management Group Management uninstalls all resources in the group. When a resource is referenced, it cannot be forcibly uninstalled.
Resource Locations
// Configuration file Method
ConfigFile cf;
Cf. load ("resources. cfg ");
// Go through all sections & settings in the file
ConfigFile: SectionIterator seci = cf. getSectionIterator ();
String secName, typeName, archName;
While (seci. hasMoreElements ())
{
SecName = seci. peekNextKey ();
ConfigFile: SettingsMultiMap * settings = seci. getNext ();
ConfigFile: SettingsMultiMap: iterator I;
For (I = settings-> begin (); I! = Settings-> end (); ++ I)
{
TypeName = I-> first;
ArchName = I-> second;
ResourceGroupManager: getSingleton (). addResourceLocation (
ArchName, typeName, secName );
}
}
// Hard Encoding
ResourceGroupManager * rgm = ResourceGroupManager: getSingletonPtr ();
Rgm-> addResourceLocation (".../../media/packs/OgreCore.zip", "Zip", "Bootstrap ");
Rgm-> addResourceLocation (".../../media", "FileSystem", "General ");
Rgm-> addResourceLocation (".../../media/fonts", "FileSystem", "General ");

Initialization
At least one rendering window must be created before initialization. This is because GPU resources may be created during script analysis, which requires rendering.
Context.
// Initialize all of the previusly defined resource groups
ResourceGroupManager: getSingleton (). initialiseAllResourceGroups ();
// Or, alternately, initialize the defined resource groups one at a time
ResourceGroupManager: getSingleton (). initialiseResourceGroup ("General ");
ResourceGroupManager: getSingleton (). initialiseResourceGroup ("Bootstrap ");
Uninstall
Resources can be detached at any time (in a group or in a single way). Resources in use are not detached.
Detach as a group
ResourceGroupManager: getSingleton (). unloadResourceGroup ("Bootstrap", true );
ResourceGroupManager: getSingleton ().
UnloadUnreferencedResourcesInGroup ("Bootstrap", true );
True indicates that only the resource data is detached and the resource instance is not deleted. It can be reloaded. Some resources are marked
"Nonreloadable", this type of resource cannot be uninstalled using the above method.
Clear or destroy resource groups
Clearing only unmounts resources and detaches resource indexes. destruction not only cleans up resources, but also removes itself from the Resource Group.
ResourceGroupManager: geSingleton (). clearResourceGroup ("Bootstrap ");
ResourceGroupManager: geSingleton (). destroyResourceGroup ("Bootstrap ");
Detach an instance
// Assume that pEntity is a valid pointer to an instance of Entity
MeshPtr meshPtr = pEntity-> getMesh ();
MeshPtr-> unload ();
Attach/reload a Resource Group
ResourceGroupManager: getSingleton (). loadResourceGroup ("Bootstrap", false, true)
Two Boolean variables are used to load resources of different resource types, one for "Normal" resources, and two for "World geometry"
Resource Group loading notification
Class LoadingProgressListener: public ResourceGroupListener
{
Public:
// Fired when a group begins parsing scripts
Void resourceGroupScriptingStarted (const String & groupName,
Size_t scriptCount ){}
// Fired when a script is about to be parsed
Void scriptParseStarted (const String & scriptName ){}
// Fired when the script has been parsed
Void scriptParseEnded (){}
// Fired when all scripts in the group have been parsed
Void resourceGroupScriptingEnded (const String & groupName ){}
// Some other interfaces
}
// Register after implementation
LoadingProgressListener listener (m_progressMeter );
ResourceGroupManager: getSingleton (). addResourceGroupListener (& listener );