Comparison between ogre and OSG

Comparison between ogre and OSG

 

1 Preface

I have carefully read the official documents provided by ogre and OSG, including the openscenegraph quick guide translated by Pro ogre 3D programming, manual, and instructor Wang Rui. I also read a lot of ogre architecture source code analysis articles on the Internet. I have used OSG for simple purposes and have some knowledge about the design and programming style of the OSG scenario manager. I have used ogre in many recent projects. I have a deep understanding of ogre compared with OSG. Currently, the latest version of ogre is 1.7, and the latest version of OSG is 2.9.7.

This article is an incomplete personal comparison of the ogre and OSG 3D graphics rendering engines, this section briefly introduces their similarities and differences in terms of operation efficiency, platform support, resource management, scenario tree management, Function Support, scalability, ease of use, and related support, instead of commenting on who is superior or inferior (Of course I do not have this qualification ),

Make different choices based on different project requirements.

Because I have not used these two drawing engines for a long time, and the functions and features are incomplete, some conclusions may be unreasonable. please correct me and make common progress through communication.

2 Introduction to The Drawing Engine

2.1 ogre

Ogre is short for object-oriented Graphics Rendering Engine. It is an object-oriented and flexible 3D engine developed in C ++, is a widely used open source 3D graphics rendering library. It has been successfully applied to many 3D simulation fields, including online games and some commercial 3D simulation projects.

It aims to allow developers to develop applications or games based on 3D hardware devices more conveniently and directly. The class libraries in the engine abstract all usage details of the underlying system libraries (such as direct3d and OpenGL), and provide interfaces and other classes based on real-world objects. Ogre has the following main features:

Efficiency

The simple and easy-to-use object-oriented interface design makes it easier for you to render 3D scenes, and makes your implementation Products Independent of rendering APIs (such as direct3d, OpenGL, glide, and so on ).

A Scalable framework allows you to write better programs faster.

To save valuable time, ogre automatically handles common requirements, such as rendering status management, space cropping, and semi-transparent object sorting.

Clear and clean design with comprehensive documentation support.

It has been applied to many commercial products (especially electronic games) and proved to be a stable engine.

Platform and 3D API support

Supports direct3d and OpenGL.

Supports multiple platforms, including windows (all versions), Linux, and Mac OSX.

On Windows, you can use visual c ++ or code: blocks for compilation.

You can use GCC 3 + for compiling on Linux and Mac OSX platforms (using xcode.

Material and shader support

The powerful material declaration language allows you to maintain material resources outside the code.

Supports vertex and pixel pasters (shader), as well as low-level assembler pasters and advanced pasters, such as HLSL and glsl in CG and d3d, it also provides automatic binding for many common constants, such as the World viewpoint matrix, illumination state, and viewpoint world coordinates.

Supports all functions of Fixed rendering pipelines, such as multi-texture, multi-time rendering fusion, texture coordinate generation and modification, and independent color fusion for low-end unprogrammable graphics cards.

Supports multiple material technologies. You can design different technologies for different video card configurations. Ogre automatically selects the best technology.

Supports material levels with low level of granularity. Your materials can reduce resource consumption when they are away from the point of view.

Supports loading textures from PNG, JPEG, TGA, BMP, DDS, and other files; supports uncommon 1D textures, stereo textures, stereo box textures, and compressed textures (dxt, s3tc ).

You can use the plug-in to provide and update textures in real time, such as videos.

Supports projective texturing ).

Grid Meshes

Flexible grid data formats are supported, independent of vertex cache, serial number cache, vertex declaration, and cache ing.

Supports progressive gridded levels that can be generated automatically or manually.

It supports the surface implemented by the bé-Zeri spline.

Batch drawing of static ry.

Animation

Support for complex skeleton Animation

Flexible shape animation support

Scene node animation and spline interpolation are supported.

Normal animation paths support pluggable object adapters (not very clear. For details, refer to the instructions on the official website)

Scenario features

It has an efficient and highly configurable scenario manager and supports multiple scenario types. Use the default Field

Organization method, or use your own scenario organization method by writing plug-ins in person.

The bspscenemanager plugin is a quick indoor Renderer that supports loading quake3 levels and shader script analysis.

Multi-level scene organization system. Scene nodes support attach of objects, and drive the motion of the attachments together, achieving a motion inheritance system similar to joints.

Special effects

Particle systems include the emitter and the affector that can be extended by writing plug-ins ). With the script language, you can set and change particle attributes without re-compiling. Supports and automatically manages particle pools to improve particle system performance.

Supports the sky box, Sky Area, and sky dome, which is very simple to use.

Announcement boards are supported for special effects.

Automatic Management of transparent objects (the system automatically sets the Rendering sequence and depth buffer for you)

Other features

Resource management and document loading (zip and pk3 ).

Supports an efficient plug-in architecture that allows you to expand the engine without re-compiling.

Using "controllers", you can easily change a value. For example, you can dynamically change the color of a spacecraft shield through the life value.

Memory debugging manager that supports Memory Leak Detection

You can use the referenceapplayer routine to learn how to enable ogre to work with other libraries, such as an ode library that collides credibility.

Xmlconverter can be used to convert binary format files and XML files to facilitate communication and editing.

2.2 OSG

OSG is short for openscenegraph. It is an open-source, cross-platform graphics development kit. It is designed for high-performance graphic application development such as aircraft simulation, games, virtual reality, and scientific computing visualization. It is based on the concept of scene graphs. It provides an object-oriented framework on OpenGL to enable developers

Optimized the calling of underlying graphics, and provided many additional utilities for rapid development of graphics applications.

It is completely written by standard C ++ programs and OpenGL. It makes full use of STL and design patterns and gives full play to the advantages of open-source development models to provide a free development library, it also focuses on user needs. With the use of a full-featured scenario diagram, the key advantage of openscenegraph lies in its performance, scalability, portability, and rapid development.

(Productivity), more specifically:

Performance

Supports view frustum culling, occlusion culling, small feature culling, and vertices) openGL state sorting, vertex array, vertex buffer objects, OpenGL coloring language, and display lists as part of the scene graph kernel. They make openscenegraph a high-performance graphics library. Openscenegraph

You can also customize the drawing process. For example, you can customize the grid of the continuous detail level (Clod) of the scene chart (see virtual terrain project and delta3d ).

 

Quick Development

The scenario graph kernel encapsulates most of the latest extended OpenGL functions, provides rendering optimization features such as removal and sorting, and also provides a complete set of libraries that can quickly develop high-performance graphics applications. Application developers can focus more on the substantive content and how to manipulate them, instead of the underlying code. By learning existing scenario diagrams, such as mongomer and Open Inventor, combining them with modern software engineering concepts like design patterns, coupled with a large amount of feedback from early development cycles, it is possible to design a clear and scalable library. Users can easily adapt to openscenegraph and integrate it into their own applications.

 

Data Loading

To read and write databases, the database supports the dynamic plug-in mechanism of the database (osgdb) to support a large number of data formats, currently, 55 plug-ins are released to support 3D data and image format loading.

Supported 3D data formats include Collada and Lightwave (. lwo), alias wavefront (. OBJ), OpenFlight (. flt), terrapage (. txp), carbon graphics GEO (. GEO), 3D Studio MAX (. 3DS), peformer (. pfb), AutoCAD (. DXF), quake Character Models (. md2), direct X (. x) and inventor ASCII 2.0 (. iv)/FIG 1.0 (. WRL), designer workshop (. DW), ac3d (. AC) and built-in. osg ascii text format.

Supported image styles include ,. DDS (including a series of compressed MIP texture images ),. with TGA and QuickTime (In The OSX Environment), the full range of high-quality and anti-sawtooth fonts can also be supported by the FreeType plug-in, and font-based images can also be supported. txf plug-in support.

You can also generate large-scale terrain space data (multi GB) by using a virtualplanetbuilder to view the data using openscenegraph's built-in data paging scheduling support.

 

Node toolbox

This scenario chart also has a set of node tool sets, which can be compiled in your application or independently loaded at runtime:

Osgparticle-Particle System

Osgtext-high-quality anti-sawtooth text

Osgfx -- special effect Framework Structure

Osgshadow-shadow Framework Structure

Osgmanipulator-Interactive Control

Osgsim-effects related to Virtual Simulation

Osgterrain-terrain rendering

Osganimation-Animation

Osgvolume-Volume Rendering (supports medical data through DICOM INS)

 

Portability

The scenario graph kernel has been designed to be as little dependent on a specific platform as possible, and a few have exceeded the standard C ++ program and OpenGL. This makes this scene map can be quickly transplanted to most systems-initially in IRIX development, and then transplanted to Linux, and then to windows, then FreeBSD, Mac OSX, Solaris, HP-UX, aix or even playstation2!

The scenario graph kernel library is completely independent of the window operating system, allowing users to add their own designated window libraries and applications to it. In the released version, the osgviewer Library provides built-in window support, supports windows (win32), Unix (X11), and OSX (carbon ). The osgviewer library can also be easily integrated with your window development kit, as part of the OpenSceneGraph-2.0 release, there are examples of how to demonstrate in QT, glut, fltk, SDL, wxwidget, use in cocoa and MFC.

 

Scalability

The scalability of the scenario graph kernel makes it not only run on portable devices, but also on high-end multi-core, multi-GPU systems and clusters. This may be because the scene graph kernel supports multi-graphic rendering environments (multiple graphics contexts) for OpenGL display lists and texture objects ), the process of removing and plotting the traversal is designed to hide the rendered data as a local variable, so that the scene graph kernel can be used in almost read-only mode. In this way, multiple-to-be-removed-the rendering process runs on multiple CPUs, And the CPU is bound to multiple graphics subsystems. Support for rendering environments and multithreading of multiple graphics devices can be easily used in osgviewer. All the examples in the released version can be run in multiple threads and GPUs.

 

Multi-language support

Openscenegraph supports multiple languages in the form of community projects, such as Java, Lua, and python.

3. Similarities and Differences between ogre and OSG

Through the introduction in the previous section, you can get a general idea of the features of the two 3D drawing engines, and easily notice the similarities and differences between the two. The two are described as follows:

Design and System

If you have used traditional and basic methods for 3D application development (in other words, you have experience using underlying APIs such as OpenGL or direct3d ), you will understand that they have similar and cumbersome processes:

You can call the API to set the rendering status, call the API to send the ry information, call the API to notify GPU rendering, clean up, and return to the first step until a frame is rendered and enters the next frame. This process will bring you into a mess of API operations. Compared with real applications, you may be wasted in basic ry operations. If you use an object-oriented method to render a ry, you can extract it from the Ry-level processing work and then process the specific scenario and objects in the scenario. The objects include: movable objects, scenes consisting of static objects, lights, cameras, and others. You only need to put the object in the scene. The ogre or OSG rendering engine can help you complete messy geometric rendering. This is also why we do not directly use OpenGL or d3d when developing 3D applications.

Ogre and OSG have many commonalities in architecture design. They use the following design concepts and tools to design and build the system to ensure system efficiency, portability, and scalability:

ANSI Standard C ++

C ++ standard template library (STL)

Design Patterns (gamma95)

Some design patterns, such as abstract factory, listener, adopter, and Singleton, are used to improve the scalability of libraries and facilitate collaboration with other libraries. For example, the OSG and ogre libraries both have a large number of powerful plug-ins, and can work with third-party interface libraries (such as QT, MFC, and wxwidget.

But there are also some obvious differences between the two. Ogre is an object-oriented 3D rendering engine. Compared with the explicit process-oriented APIs of OpenGL and d3d, the abstract object-oriented APIs are more concise and convenient to use. While OSG provides many convenient feature packages based on OpenGL, and does not abstract underlying graphical interfaces (OpenGL. The following describes the advantages of object-oriented in pro ogre 3D programming:

 

Well, today's graphics engines are like any huge software system. It was slim at the beginning, but quickly turned into an amazing and complicated monster, making it hard to understand. Such a large system is difficult to manage, and any modifications to the system may affect its reliability. In such a field that constantly introduces new technologies and means, modification is essential. A large number of C function calls cannot improve this situation-even if all functions are written by the same person. It is often found that a small piece of code will become complicated and difficult in a few months, and how to organize these functions will become a challenge.

Objects are a common method to solve complexity problems. It gradually breaks down the code into functions and organizes functions and State data into classes to represent various concepts in reality. It allows you to hide complexity in easily identifiable code packages and only expose simple and easy-to-use interfaces. In this way, you have the "Building Materials" that can be built together ". You can also organize these materials to make them have consistent external interfaces, but the methods for implementing these interfaces are different internally. This reduces complexity because developers only need to learn one interface.

 

At the same time, ogre only focuses on plotting and is not responsible for other modules, such as user interfaces, sounds, networks, and collision detection. Other modules are in the form of plug-ins. OSG provides more functions, such as functions not available in the former, such as virtual simulation, volume rendering, and paging terrain loading (the latest ogre1.7 also introduces some related functions. Therefore, OSG can be used for projects that use existing mature modules, and Ogre can be used for products that are more mature and commercialized.

 

Platform support

From the previous feature analysis, we can see that ogre and OSG have different emphasis on platform support. For example, ogre focuses on mature commercial platforms, such as d3d and mainstream graphics operating systems, thus, you can. OSG emphasizes supporting multiple operating systems, such as FreeBSD, Solaris, HP-UX, And Aix. OSG may support OpenGL platforms. Because most games and commercial software are based on d3d, And ogre provides good support for d3d, it is a good choice to start a game.

 

Resource management

Regardless of the terrain, texture, Font, and other objects, drawing them requires different resources. How to load, reuse, and uninstall these resources is very important. Therefore, there are dedicated classes to accomplish these tasks. Ogre provides a perfect resource management system, including the separation of materials, shader, particle system, and other resources from outside the code. Ogre defines a powerful material declaration file, which can be used to directly define texture, drawing status, shader, and other information. It also supports simple variables and declaration inheritance from ogre1.6, this greatly facilitates resource management and makes code clearer.

In the graphics engine, there are a lot of code for status management and context-related operations. Encapsulation can put the code in an independent resource declaration file, so that the code is easier to understand. Besides, encapsulation avoids code duplication and makes the program more reliable. These resource declaration files are also independent from the platform, which is a major feature of ogre as a mature 3D rendering engine.

 

Scenario tree management

Both ogre and OSG have a scenario tree to manage information about the entire scenario. The scenario tree can be used to conveniently manage scenario objects, you can also adjust the soft crop and draw sequence before submitting the painting operation to the underlying interface. At the same time, the content of each node in the scenario tree of ogre and OSG is different.

First, the ogre operation on the scene graph is maintained at the interface level; it does not care about the specific Algorithm Implementation of the image. In other words, ogre only uses APIs to operate scene graphs, ignoring specific algorithm implementations. Second, the scenario graph interface of ogre is only responsible for maintaining the scenario structure. The node does not contain any inherent content and management methods. The specific content is

Placed in a renderable object that provides all the geometric shapes (including active or all others) in the scenario ). Their rendering properties (or material) are included in the Entity object, which also contains one or more subentity objects, these are actually

To render objects.

The top of the scene graph tree structure is a root node. Extending down from the root node, each group of nodes contains geometric information and rendering status information used to control its appearance.

Orge "Pro ogre 3D programming" mentioned:

Although I have not obtained an authoritative argument, I still firmly believe that the design of the separation of scenario diagrams and scenario content must be the most eye-catching part of the entire ogre project. Although it seems to be so easy to understand, it is still hard for those who stick to the "traditional design method" to complete the scene map design.

In traditional design (that is, used by many commercial and open source 3D engines), the scenario content and structure are put into an inheritance system, and the scenario content is stiff as a subclass of the scenario node. I assert that this is an extremely failed design plan. If you do not modify all child classes, there is basically no way to change or expand the graphics algorithm. Therefore, it is very difficult to modify the interface of the base class, which leads to difficulties in future maintenance work. In addition, this design idea of "all nodes come from the same node type" will make the entire program solidified and difficult to reuse (at least from the maintenance point of view ):

When a new basic class function method or attribute is added, all these are forced to be inserted into all subclasses, no matter whether they are required or not. In the end, even a small modification to the basic skills will be triggered, making development and maintenance difficult and controllable. This bad design concept makes people suffering, hoping to get rid of this logic

New Design Method.

 

We can see that this scenario tree management method is selected for Ogre for maintainability and scalability. With the powerful code resource separation function of ogre and scalable multi-scenario manager support capabilities, this concise scenario tree management design has achieved great success.

 

Ease of use

To enable code to support d3d and OpenGL engines, we do not recommend that you directly use APIs of d3d or OpenGL in ogre programming, and the rendering pipeline is different from the underlying APIs, this increases the difficulty of getting started and the steep learning curve. The OSG is only based on a single underlying API of OpenGL. Therefore, you can directly add OpenGL API calls to the OSG project. Generally, it is only the only solution, to use the new OpenGL extensions not included in OSG.

From this point of view, OSG is more suitable for projects that require the use of new graphics technology, while ogre is more suitable for general technology, mature and requires the use of more suitable game d3d engine projects. As mentioned above, ogre has a powerful and fully functional resource manager, which can greatly reduce resource management complexity and improve resource loading, allocation and utilization efficiency. This helps to separate the artist, effect and code, and make the logic clearer during programming. This is a mainstream direction of programming. For example, Nokia's QT user interface library has been evolving in this direction.

 

Related Support

Ogre and OSG also have this difference in support for some resources and functions. For example, ogre does not support a wide range of mesh file formats like OSG. In fact, ogre only supports its own unique. Mesh file, while other models can only be loaded by converting to this format. At the same time, ogre does not support Input and Output. You need to use the independent module OIS (Object Oriented Input System) to support input and output operations. In general, ogre focuses on 3D rendering, and other functions required by 3D applications can be implemented by plug-ins or other libraries. OSG provides more support, such as osgvolume, osgsim, and osgal.

4. Summary

This article briefly introduces some features of ogre and OSG and compares their functions. with simplified 3D graphics programming, the two maintain their own unique design path. Ogre features a mature design model, excellent resource management methods, and good cross-platform (especially d3d ); OSG features a wide range of open-source projects and documents and many ready-made functional modules.

The same is an open-source project. OSG is a large-scale development team with more than 200 developers, while ogre has a small and powerful development team (currently a total of 7 developers ). Ogre is relatively active and features are updated frequently, which is important for the graphic rendering field with rapid technological changes. So far, many commercial games have used the Ogre Graphics Rendering Engine, such as domestic online games "tianlong Babu" and recently popular games "torchlight 2009.10) online games, such as "Zero gear. OSG tends to be in the virtual simulation field and emphasizes that the function of the database is better than the programming theory. Both of them have a powerful open-source community and are open-source projects, allowing you to conveniently view the source code at any time, which is very helpful for developing applications.

 

5 References

[1]. openscenegraph Quick Start Guide, Paul martz [us], translated by Wang Rui Qian Xuelei, 2007

[2]. Pro ogre 3D programming, Gregory juker, translated by Li Xudong, 2006

[3]. Ogre manual v1.7 ('cthugha'), http://www.ogre3d.org/docs/manual/

[4]. Ogre features, http://www.ogre3d.org/about/features

[5]. OSG introduction, http://www.openscenegraph.org/projects/osg/wiki/About/Introduction