Ogre Reference Manual (i) 2 core objects

Description

Translation from Ogre 1.81 Manual, without prejudice to the understanding of the case, to reduce the time of reading and translation of the workload

This is done only by removing the modified part of the text, and does not reduce any of the knowledge points in the original document, which can be used as the equivalent reference manual

In addition to some difficult to understand the parts have been modified, or by "attached" to do the labeling

If you find a difficult to understand part, you can reply, I will make the original changes or reply

Ogre Reference Manual The first two chapters for the basic introduction, relatively streamlined

The core of the content is chapter III, especially section 3.1

The seventh and fifth chapters, in turn, are worth taking time to read through.

1 Introduction

Slightly...

2 Core Objects

is the main class structure of Ogre

The top is the root object, which is the portal using Ogre. This class allows you to create all top-level objects, such as Scenemanager, Rendersystem, Renderwindow, and load plugins. If you don't know where to start, root can do everything for you, usually root is more of an organizer and service object by providing another object to do the actual work.

Ogre the main classes can be divided into 3 parts:

Scene Management

This involves the content of the scene, how to organize it, how to view it through the camera, etc. The classes here provide a real-world visual display interface. That is, you do not need to tell OGRE: "Set these render states and render three polygons"; you just have to say, "I need to put something here, here and here, use their material, and then render from this perspective", and the rest will let Ogre handle it.

Resource Management

All rendering requires resources, whether it is geometry, textures, fonts, and so on. It is important to manage the load, reuse, and uninstallation of these resources with care, which is what this section does

Rendering

Ultimately, these need to be displayed on the screen, where the underlying rendering pipeline is involved. Rendering system API-specific objects such as buffers, render states, and similar things are pushed to the rendering pipeline. The scenario management subsystem renders a high-level scene to the screen by using this section

Note the edges in the graph scatter some plugins (plugins). The ogre is designed with an extensible design, which is typically implemented via plug-ins. Many classes of Ogre can be inherited and extended, either by changing the scene organization through a custom scene manager, by adding new rendering system implementations (i.e., Direct3D or OpenGL), or by loading resources from other sources (for example, from a network or database). Here are just a few simple things to say about what plug-ins can do, and you'll see that plug-ins are available in almost every aspect of the system. In this way, Ogre is no longer a strictly pre-defined solution, and you can expand to address all the issues you need to address

2.1 Root

The root object is the entry point of the Ogre system, which must be first created and last destroyed. In the sample program, I chose Root as a member of MyApplication to ensure that Root was created when it was created and deleted when it was deleted.

The root object allows you to configure the system, for example, through the Showconfigdialg () method. This method detects all rendering system options and displays a dialog box for user-defined resolution, color depth, full screen options, and so on. The user-selected option is also set so that you can initialize the system directly.

The root object provides methods for obtaining pointers to other objects, such as Scenemanager\rendersystem and other resource managers.

Finally, if you want to run ogre in continuous rendering mode, that is, you want to always refresh all render targets at the fastest speed (standard practice for games or demos, not for windowing tools), you can call Startrendering () and call the method to enter a continuous rendering loop, Until all render windows are closed, or any framelistener indicate that you want to terminate the loop.

2.2 Rendering System Rendersystem

Rendersystem is actually the underlying 3D API abstraction class. Used to send rendering operations to the 3D API and to set various rendering states. The design is abstract because the implementation is related to the rendering API, and each render API corresponds to a specific subclass (example D3drendersystem for D3D). With root::initialise initialization, you can use Root::getrendersystem () to get the Rendersyetem for the current rendering API.

In general, applications do not need to manipulate rendersystem objects directly, and the need for all render objects and the usual settings can be done through scenemanager\material and other classes used in the scene. Use the Rendersystem object only if you need to create a multi-render window (a completely separate window, not a multi-viewport-like split-screen effect that can be implemented through Renderwindow) or require additional advanced features.

For this reason, this tutorial does not discuss Rendersystem objects, and you can assume that Scenemanager will handle calls to Rendersystem at the right time

2.3 Scene Manager Scenemanager

In addition to root, this is probably the most important object and the most commonly used object in the program. The scene manager is responsible for managing the scene content for engine rendering. Responsible for selecting the most appropriate technical organization scenario, creating and managing all cameras, movable objects (entity entities), lights and materials (surface properties of objects) and managing irregular stretches of static geometry: World geometry, commonly used to represent non-movable parts of a scene.

You need to create a camera with the scene manager to create or remove lights. You do not need to maintain a list of all objects, and the scene manager provides a named collection (map) for managing all scene objects that you might use. can refer to getcamera,getlight,getentity and other methods

Most of the interaction between you and the scene manager is in the scene creation phase. You will invoke a number of methods (possibly driven by input files containing the scene data) to load the scene, and if you use the Framelistener object, you can dynamically modify the scene content in the render loop

Because different scenarios require different algorithms to determine which objects need to be sent to a rendering system for better rendering performance, the scene manager is designed to be inherited for different scene types. The default scene manager can be used to render a scene, but with little or no scene organization, you can't expect it to have high performance when rendering large scenes. The purpose of this design is to achieve optimal performance by using specific subclasses designed for different scene types to organize the scene. For example, you can use Bspscenemanager based on the spatial binary space partition,bsp to optimize large-scale indoor scene rendering.

Applications that use Ogre do not need to know which subclass to use. By calling Root::createscenemanager and passing a scene type parameter (St_generic/st_interior), the application ogre can automatically select subclasses that fit the scene type. If there are no specialized subclasses, the default Scenemanager will be used. This allows the developer to replace the scenario implementation that was not previously optimized by adding a new specially optimized version without modifying any code.

2.4 Resourcegroupmanager

Resourcegroupmanger is the center of loading reusable resources such as textures or meshes (mesh). You can group resources to load and unload as needed. This includes some ResourceManager for managing various types of resources, such as Texturemanager\meshmanager. Here, resources are seen as a set of data that can be loaded from somewhere for ogre use.

ResourceManager guarantees that resources can be shared across the ogre engine once they are loaded, as well as the memory required to manage resources. You can also find the resources you need in multiple locations, including multiple paths, compressed documents (Zip files).

Usually you do not interact directly with the resource manager. The resource manager can be called automatically by other parts of the ogre when needed, such as when you access the texture of the material and Texturemanager will be called automatically. If needed, you can directly invoke the appropriate resource manager to reload the resource

One thing you probably need to do is tell the resource manager where to look for resources, which can be done by root::getsingletion (). Addresourcelocation (), which actually passes this information to Resourcegroupmanager.

Because there is only one instance per resource manager, you can reference the Resource manager in the following ways:

Texturemanager::getsingleton (). SomeMethod ()

Meshmanager::getsingleton (). SomeMethod ()

2.5 Mesh Mesh

A mesh object represents a detached model, a complete set of geometries, usually small at the world scale, used to represent moving objects, not for irregular stretches of geometry such as backgrounds.

Mesh is also a resource that is managed through Meshmanager. Typically loaded by ogre custom. Mesh format files. Mesh files can be exported from the modeling tool and can be processed by the mesh tool

You can use the Meshmanager::createmanaual method to create a mesh manually.

Mesh is the basis for individual movable objects in the world, which are called entity (entities)

You can use animations for mesh, refer to 8.1 skeletal animations

2.6 Entity Entities

An entity is an instance of a movable object in a scene. It could be a car, a man, a sword in his hand, and so on. The only assumption is that it does not need to occupy a fixed position in the world.

Entities are created based on mesh, and multiple entities can be based on the same mesh because multiple copies of the same type of object are often required in the scene

You can call the Scenemanager::createentity method to create the entity and specify the mesh name (A.mesh) to use. Scenemanager ensures that the mesh is loaded by calling Meshmanager. Only one copy of the mesh will be loaded.

Entities are considered part of the scene only after they are associated to the scene node (scenenode). By associating to a node, you can establish complex position and orientation relationships between entities. You can indirectly set the entity position by modifying the location of the node.

When the mesh is loaded, it is automatically accompanied by some materials. Mesh can be associated with multiple materials (different parts with different materials). When you create an entity, the corresponding material is automatically used, and you can change the material of the solid, allowing entities created with the same mesh to use different materials.

This is actually because the mesh is made up of multiple submesh, and each Submesh as part of the mesh can use different materials. If the mesh uses only one texture, only one submesh should be used

When entity is created based on mesh, it is also composed of subentity, each subentity corresponding to a submesh. The subentity can be obtained through entity::getsubentity and the material can be changed by. Setmaterialname. In this way, you can create different skins for each entity.

2.7 Material Material

The material controls how objects are rendered in the scene, specifying the surface properties of the object, such as color reflection, highlighting, how many texture layers are used, how many images are applied, how they are mixed, what special effects such as environmental mapping, what cropping method, how the texture is filtered, and so on. Basically, apart from the shape, the appearance of the object is controlled by the material

Materials can be created manually via scenemanager::creatematerial or loaded at run time with script files, referencing the 3.1 material script

Scenemanager manages the list of available materials in the scene. The list can be added via scenemanager::creatematerial, or it can be added when the mesh is loaded. Regardless of how the material is added to Scenemanager, the following default properties are initially available:

• Ambient reflectance = Colourvalue::white (full)
• Diffuse reflectance = Colourvalue::white (full)
• Specular reflectance = Colourvalue::black (None)
• Emissive = Colourvalue::black (None)
• shininess = 0 (not shiny)
• No texture layers (& hence no textures)
• Sourceblendfactor = sbf_one, Destblendfactor = Sbf_zero (opaque)
• Depth buffer checking on
• Depth Buffer Writing on
• Depth buffer comparison function = Cmpf_less_equal
• Culling mode = Cull_clockwise
• Ambient lighting in scene = Colourvalue (0.5, 0.5, 0.5) (Mid-grey)
• Dynamic Lighting Enabled
• Gourad Shading Mode
• Solid Polygon Mode
• Bilinear Texture Filtering

You can call Scenemanager::getdefaultmaterialsettings () to modify the returned material to change these settings

Entities are automatically associated with the material when created through mesh, because the mesh is usually set to the desired material. You can change the material of the solid, refer to the 2.7 entity

2.8 Surface Overlay

Overlay allows 2D or 3D elements to be displayed on top of normal scene content for HUD (head-up digital display, heads-up displays), menu system, status bar, and more. The frame-rate statistics panel provided by Ogre is an example of a overlay. The overlay can contain 2D or 3D elements, and 2D can be used for hud,3d that can be used in the cockpit and so on before other scenarios.

You can create overlay by scenemanager::createoverlay or by defining them in the. Overlay script. In fact, the latter is more appropriate because it is simple and does not require recompiling the code. You can define any number of overlay, whose initial default is hidden by calling. Show (). Multiple Overlay,zorder can be displayed at the same time through Overlay::setzorder settings.

Creating 2D Elements

Overlayelement abstracts the details of the 2D elements added to the overlay. All elements that can be added to the overlay inherit this class. The user can (recommend) customize the subclass to implement the custom control. Overlayelement contains some of the common properties, including Size\position\materail, and so on. Subclasses can extend support for more complex properties and behaviors.

An important built-in subclass of Overlayelement is Overlaycontainer. Overlaycontainer is similar to overlayelement, where the difference is that it can contain other overlayelement, group them, and provide easy-to-arrange local coordinate source points.

The third important class is Overlaymanager. Whenever an application needs to create a 2D element to add to overlay (or container), it needs to call overlaymanager::createoverlayelement. The type of the element being created is identified by a string, which is to allow the new overlayelement type to be registered through the plug-in. For example, to create a panel type element, you can call Overlaymanager::getsingleton (). Createoverlayelement ("Panel", "Mynewpanel");

Adding a overlay element to a

Only Overlaycontainer (containers) can be added directly to overlay. This is because each container establishes a zorder for the inner element, so that when you nest multiple containers, the zorder of the inner container will be larger than the outside, guaranteeing proper display. You can simply call overlay::add2d to add the container to the overlay.

If you want to add child elements to the container, you can call Overlaycontainer::addchild. The child elements can be ovelayelement or Overlaycontainer. The position of the child element is defaulted relative to the upper-left corner of its parent container.

Coordinates

Ogre can set element size and position using two 2D coordinate systems

pixel mode ( Pixel )

The pixel mode is simple, the upper-left corner is (0,0), and the lower-right corner is based on the screen resolution.

This is useful when you need to set an exact size for an element, and if you don't mind adjusting the resolution it will make the element smaller on the screen (you might want to). In this way, only through the Align option can you keep the element centered or right in a variety of resolutions, you can set the horizontal and vertical coordinate source points to the right, bottom, or middle by the Align option to place the elements in the appropriate position without knowing the resolution; in relative mode, You just have to use the correct relative coordinates.

Relative Mode ( relative )

Useful when you want elements to remain the same size on the screen at various resolutions. The upper-left corner of the relative mode is (0,0), and the lower-right is (+). If you place the element in (0.5,0.5), the upper-left corner of the element is exactly at the center of the screen, regardless of the resolution. The same principle applies to size. Note, because the screen aspect ratio is typically (1.333:1), the size of the (0.25,0.25) element is not a square.

Overlay Transform

A good feature of overlay is that it supports overall rotation, scrolling, and zooming. Reference Overlay::scroll/rotate/scale

Overlay Script

Overlay can be defined by script, refer to 3.4

Gui

Overlay is actually designed as a non-interactive screen element, although you can also use it to make a coarse GUI

If a full GUI solution is required, Cegui (http://www.cegui.org.uk), Mygui (http://mygui.info/) or Librocket (http://librocket.com/) are recommended

Ogre Reference Manual (i) 2 core objects