GSoC/GCI Archive
Google Summer of Code 2013

OGRE (Object-Oriented Graphics Rendering Engine)

Web Page:

Mailing List:



What Is OGRE? OGRE (Object-Oriented Graphics Rendering Engine) is a scene-oriented, flexible 3D engine written in C++ designed to make it easier and more intuitive for developers to produce applications utilising hardware-accelerated 3D graphics. The class library abstracts all the details of using the underlying system libraries like Direct3D and OpenGL and provides an interface based on world objects and other intuitive classes.

What can it do?
Lots of things! See the features page for an up-to-date list of the current features. Also, take a look at the screenshots page to see for yourself the kinds of eye candy OGRE can pump out.

Is OGRE A Game Engine?
No. OGRE can be (and indeed has been) used to make games, but OGRE is deliberately designed to provide just a world-class graphics solution; for other features like sound, networking, AI, collision, physics etc, you will need to integrate it with other libraries, something several frameworks have done, and we have a collision / physics reference integration library as an example in our distribution.

Why? Well, one reason is that not everyone who needs a 3D engine wants to make games, so we don’t assume that you do – you can use OGRE for games, simulations, business applications, anything at all. Secondly, even within the games industry, requirements can vary widely; for example a MMORPG will need a very different kind of network library than an FPS, and a flight sim will need a different kind of collision / physics system to fighting game. If OGRE included all these features, we would be enforcing a particular set of libraries on you, with an inbuilt set of assumed requirements, and that’s not good design. Instead, we provide a very integration friendly API and let YOU choose the other libraries, if you want them. Many experienced game developers have expressed their approval of this approach, because there are no inbuilt constraints. It can be more daunting for newer users who just want to build another FPS-style game, but for those people there are a growing number of existing frameworks using OGRE which provide a complete solution using a given combo of libraries; but it’s important to realise that OGRE itself will always remain separate, flexible enough to be incorporated into any of these. The principle is of collaboration and integration with other libraries, rather than assimilation of them, a standard tenet of component-based design.

Why should I consider using OGRE (rather than the other zillion 3D engines out there)?
Many other engines, whilst technically impressive, lack the cohesive design and the consistent documentation to allow them to be used effectively. Many of them have long features lists, but have the feel of a bunch of tech demos lashed together with twine, with no clear vision to hold them together. Like any other software system this becomes their downfall as they become larger. Most other engines are also designed for one particular style of game or demo (e.g. first-person shooters, terrain roamers).

OGRE is different. OGRE is design-led rather than feature-led. Every feature that goes into OGRE is considered throughly and slotted into the overall design as elegantly as possible and is always fully documented, meaning that the features which are there always feel part of a cohesive whole. Quality is favoured over quantity, because quantity can come later – quality can never be added in retrospect. OGRE uses sound design principles learned, tried and tested many times in commercial-grade software – the object-orientation mentioned in it’s moniker is just one of those approaches – frequent use of design patterns is another. The core development team is kept deliberately small, and all of its members are veteren software engineers with many years of real-world experience. Patches are welcomed from community, but they undergo a strict review for both quality and cohesion with the Ogre philosophy before being accepted.

OGRE does not assume what type of game or demo you want to make. It uses a flexible class hierarchy allowing you to design plugins to specialise the scene organisation approach taken to allow you to make any kind of scene you like. Want to render indoor levels fast? Fine, use the BSP/PVS plugin scene manager which has already been written. Want an outdoor landscape? Again, use another plugin scene manager. The rest of the engine continues to function exactly as before.

So the short answer is – if you favour design quality, flexibility and clear documentation, choose OGRE. You know it makes sense. [IMAGE]

Is it really free?
The Ogre source is made available under the MIT License, which basically means you can use it however you like as long as you include the content of our COPYING file somewhere in your application. The source to your application, or your modifications to Ogre do not have to be released (although it would be nice if you did). See the licensing page for full licensing terms.

How do I find out more?
If you want to find out about the principles under which OGRE has been developed and to get a quick overview of the design, go to the OGRE Manual now. You can also read the tutorials to help you get started, and then reference the API documentation online.

The best way to appreciate OGRE is to use it. I recommend using Mercurial to download the latest version since the code is under constant improvement. If you don’t want to use Mercurial, a snapshot is released periodically for download. For both these options, see the downloads page.

If you have any specific questions, just email the project manager using the email address listed on the team page.



  • DirectX 11,Tessellation Samples The DirectX 11 Render System is not fully completed on Ogre3D. There is a lot of space for core improvements, like multi-threading support, use immutable state object for state management, read back depth-stencil buffer as texture, support new texture codecs BC6/BC7. Moreover tessellation feature is not really used. This feature can do a lot more like displacement mapping support, complex geometry generation for water and terrain with tessellation stages, render physically correct movements with compute shader and tessellation stages. Finally, I want to improve how Ogre3D works on winRT.
  • Improve Progressive Mesh algorithm It's waste of performance to have high quality models in faraway distance. Games can gain lot of performance by reducing faraway models and Ogre provides two methods for this: Manually created mesh LOD (for example in Blender) and generated mesh LOD. Blender supports nice reduction algorithms, why don't we just use that? First manually created mesh LOD creates a separated mesh for each LOD level, which means vertex data is duplicated for each LOD, which makes a big memory overhead. The memory overhead is needed, because Blender moves the vertices from original position to a calculated new position, so we need a separated vertex buffer too. Why don't we use Hoppe's algorithm or other more advanced techniques for reduction? These techniques have got the same problem as Blender. Also it would add limitations: For example if the mesh has bone weights or custom vertex data passed to a vertex shader than you can’t just insert a vertex. So the goal of my GSoC proposal is to improve current progressive mesh algorithm.
  • Ogre 2.0 Bring the project to the state of 2.0, using SIMD code, multithread-ready, much better cache utilization and SoA (structure of arrays) patterns. Traversal of Nodes & Entities will be refactored to avoid redundant transforms and cache misses.
  • OpenGL 3+ and Advanced Graphic Samples My project proposal consists of three main areas of development: 1) finish the OpenGL 3+ rendering system, 2) create and update sample applications to serve as visual tests for OpenGL 3+ features, 3) create and update functional and visual unit tests for the OpenGL 3+ rendering system
  • Resource System Redesign & Replacement Remove the existing Resource system from OgreMain, and define interfaces in OgreMain to make resource systems pluggable. Migrate the existing resource manager to use this interface. Additionally, make the loaders for meshes and other resources pluggable in the same way as is presently done for textures.