Chapter 3 design overview of Pro Ogre 3D Programming Reading Notes Part 1

Design Philosophy
Traditionally, to use Direct3D or OpenGL to render scenes and objects, you must follow a series of procedures to process the stream: Call the API to set the rendering status and call the API to send the ry information, notify the API or GPU to render the ry. Returns this to every ry until the current frame is completely rendered. The same is true for the next frame.
Using an object-oriented method to render a ry simplifies the above process. By processing various objects that make up the scenario, rather than the original ry. These objects include: movable objects, static objects (which constitute the world layout), light, and cameras. 3D APIs do not need to: Put these objects into scenarios, and Ogre is responsible for handling trivial details. In addition, objects can be manipulated in a more intuitive way, rather than using matrices. In general, we can process objects, their attributes, and call more intuitive methods, instead of using Vertex lists, triangle lists, rotation matrices, and other means to manage them.
Ogre provides an object-oriented framework, including all the rendering processing parts in the object model. The rendering system abstracts the complexity of the underlying 3D API. Scene graphics Functions are abstracted into separate interfaces, so that different scene Graphics Management Algorithms can be plug-and-play. All rendered objects in a scenario, whether movable or static, are abstracted by a group of public interfaces, these interfaces provide actual rendering operations (such as techniques and passes ).
Design highlights
1. Rational Use of the "Design Model"
Ogre uses a lot of classic design patterns. For example, the "Observer" mode is used to notify the application of a specific event. In the demo, The FrameListener enables the program to receive frame-started and frame-ended Event Notifications. The Singleton mode forces the implementation of a single instance of the class. The "Iterator" mode is used to traverse the content of the data structure.
The "Visitor" mode is used to perform certain operations on objects. The Fa C ade mode is used to abstract the underlying layer and provides a single class interface.
"Factory" is used to create an instance.
Scenario 2 diagram and content Separation
Traditionally, scene maps and content are in the same inheritance system. It requires that the content class be subclass from the scenario node, that is, the content class is inherited from the scenario node. Practice has proved that this design is very bad. First, the Ogre operation scenario graph is on the interface layer. It does not assume the implementation of a specific graphic algorithm. In fact, the image of the Ogre operation scenario only uses its signature (method) to completely ignore the underlying algorithm implementation.
Second, the graphic interface of Ogre only cares about the graphic structure and does not contain any internal access or management functions. The latter is pushed to the Renderable, and all the geometries in the scenario (movable or otherwise) inherit from it. The rendering properties (material, materials) of these Renderalbes are included in the Entity object. Entity can contain one or more SubEntity. These child entities are actually rendered objects. The following is a diagram of each object:

With this design, Scenario Management and scenario content are fully decoupled. For a scene chart, the rendering attribute becomes valid through the Movable Object ry. Note that Movable is not inherited from Scene Node. The Movable Object is attached to the Scene Node. The design and implementation of the Scene content Object are not affected when the scenario is expanded, changed, and reconstructed.
On the other hand, scene graphics do not need to know any changes in the content class. As long as you implement some simple scenario graphics "do" some interfaces you need to know. Therefore, we can attached anything customized to the scene node, such as sound information. (I heard that there is an OgreAL, which encapsulates OepnAL. I guess this is the case ).
Three plug-in Structure
OGRe is designed to be scalable. Ogre is completed through "contract-based design. Ogre can be designed as a group of components that work together. They communicate with each other through some known interfaces. This brings great flexibility, and it is very easy to implement and change a function. For example, because the metadata management in the ogre processing scenario is at the interface level, you can select the implementation of a specific algorithm at will. In addition, when you create a new implementation, it is easy to provide it to Ogre in the form of plug-ins. To achieve this, you only need to follow some interfaces defined by ogre. file archives and render systems are also provided in the form of plug-ins, as are particle systems. The attraction of the plug-in form is that in order to add the plug-in, you do not need to re-compile the Ogre library. The plug-in can be loaded at runtime.
4. hardware accelerated rendering support
Ogre is designed to only support hardware-accelerated graphic rendering. Direct software rendering is not an option. Ogre uses complete hardware acceleration capabilities, including programmable shaders. What the Unreal Engine can do is what the Ogre engine can do !! (^ _ ^, As mentioned by the author ). The Global Illumination (precomputed Radiance Transfer) directly supported by the engine has not been implemented yet, because most of these are used for non-real-time computing, so they are not a problem. currently and in the future, Ogre may only use Direct3D and OpenGL.
5. Flexible rendering queue Structure
Ogre adopts a new method to solve the rendering order of each part in the scenario. A rough look, the standard process is usually as follows: rendering terrain or world ry, rendering movable objects, rendering various effects, rendering OverLay, rendering background or sky box. however, like a typical implementation (like an integrated circuit processing module), this process is hard to change. in many examples, it is difficult to change the Rendering sequence, resulting in difficult maintenance and inflexible design. The concept of rendering queue is: Ogre renders a group of ordered queues in one way at a time, and the content in each queue has been rendered in the same way. That is, the queue itself has a priority, and the objects in the queue also have their own priorities.

In, the queue is rendered from the back to the front (Background à OveryLay), rendering from left to right in the front queue.
In this mechanism, it is very easy to re-organize the rendering order, as long as the priority is re-assigned. The queue can be customized, and the objects in the queue can also be customized. The entire queue can be "turned on" and "turned off", and the objects in the queue can also be. Each queue provides Event Notifications (such as prerender and postrender), and applications have the opportunity to change object rendering in the queue. This mechanism is useful for developing and maintaining complex programs.
Six robust Material Systems
The Ogre material is composed of one or more technique, which is a collection of pass. Pass is a material-level rendering unit, resulting in a "draw" Call of the graphic hardware. There can be multiple passes, each of which is a completely new rendering operation, including hardware rendering status change.
The most attractive feature is automatic fallback. Ogre looks up and down (in the order listed by technique) to find the most appropriate technique. Ogre also tries its best to reorganize the pass in technique to cater to the minimum technical needs. For example, the current hardware only supports a single Texture unit, and the minimum complexity of your program requires at least two texture units, then ogre Splits a pass into two, achieves the same effect by mixing two unit textures.
The Ogre material system also supports the concept of schemes. Schemes can be understood as a general "very high, high, medium, low" for different levels of graphic settings. In this case, you can define four schemes and assign techniques (plural) to each of them ). In this way, ogre's so-called technique fallback can be used to find the techniques that belong to a specific schemes. Makes material management easier.
Material scripts can also be used to complete the tasks. The code method also supports schemes and technique fallback.
Seven local optimized geometric and bone formats
Ogre uses its separate mesh and skeleton format. Data generated by the third software package cannot be directly loaded. A third file format conversion tool is available in the community, but it is not part of the Ogre library. Ogre uses its own format for efficiency.
More than eight types of Animation
Ogre supports three types of Animation: Bone animation, deformation animation, and Pose animation.
The skeleton animation binds the vertex to the skeleton. Each vertex of an object can be affected by four independent bones. Each impact is assigned a weight expressed by quantity. The skeleton animation only performs the forward kinematics mode on the key frame. Ogre currently does not support reverse animation.
Morph animation is a vertex animation technology that stores absolute vertex position information on key frames and interpolation between two key frames at runtime. Unlike Pose animation, Pose animation stores offset data rather than absolute positions. Pose animations can be mixed to form complex animations. Morph animation has limited functions than Pose animation because it stores absolute values, making it difficult to mix with other Morph animations. The Morph animation and Pose animation cannot be mixed.
All animation types can be used together with the skeleton animation.
All animation types can be executed using software or GPU hardware.
Ogre animation is based on key frames. The interpolation method has two options: Linear and cubic splines.
9. Compositor Postprocessing ~?)
It is used to create a two-dimensional, full-screen post-processing effect in a single view. for example, blur, black and white TV, and so on (Ogre has a good example) Compositor also has the concept of technique and pass similar to the material system. Multiple computations and rendering can be executed before the view is finally output. Like the fallbacks of the material, Compositor framework provides fallback processing, for example, when the output pixel format is invalid. The easiest way to understand compositor is to use it as an extension of the fragment Program (pixel rendering. The difference is that the traditional graphic pipeline only supports one clip program for each material pass, while the Compositor framework can come and go back multiple times like playing table tennis. The Compositor script is scanned on the ViewPort, so it can be oriented to any render target, which can be a rendered texture, main, and secondary rendering window. Like the material system, it can be implemented by code in addition to scripts.
10. Extended Resource Management
In ogre, the resource is defined as: rendering the ry to the rendered target to use anything. Obviously, it includes mesh, skeleton, material, overlay script, font, Compositor script, GPU program, and texture.
Each resource has its own manager, which is mainly responsible for controlling the memory usage of a specific type of resources. In other words, it controls the life cycle of the resource instance. But only one point of control: first, it can only store the same number of instances, depending on the memory allocated by this type of resources. Second, ogre will not delete instances that are being referenced by other parts.
The resource itself is actually responsible for loading itself. This is a design feature of the Resource System: manual resource loading. Manual loading means that resources are loaded and processed by calling one method instead of being implicitly loaded from the file system.
There are four statuses of resources in ogre: undefined, declared, not loaded, and loaded.
Undefined. It indicates that ogre has no idea about it.
Declare that it has been indexed in the file.
Not loaded, initialized (script, parsed), referenced, and created
It has occupied space in the memory pool managed by its resource manager.
You can use "groups" to manage and manage various resources. The relationship between resources in A group is arbitrary, depending entirely on the programmer: all resources for creating a gui can be divided into one group, and resources starting with A letter can also be divided into one group. There is a default group: General
When searching for a resource instance in ogre, the group where the resource is located is not considered. Sometimes, we can use Resource Group Life as a "namespace".
Resources in Archives are not manually loaded. Archives is a simple abstraction of common file containers. It includes the file system and ZIP file. You can implement custom archive.