We just tagged the Ogre 1.11″Rhagorthua” release, making it the new current and recommended version. We would advise you to update wherever possible, to benefit from all the fixes and improvements that made their way into the new release.
This release represents 1 year of work from various contributors when compared to the previous 1.10 release. Compared to the last Ogre 1.10 release (1.10.11), however we are only talking about 4 months. Here you will mainly find bugfixes and the architectural changes that justify the version number bump.
For source code and precompiled SDKs, see the download page. Currently the Android Java SDK is still missing. We will update the download page as it becomes available.
The 1.11 release focuses on preparing the codebase for future development instead of on new features. Some obsolete parts were removed and certain APIs adapted to be more generic. This is also reflected by the diff between
v1.10.11..v1.11.0 as: 16336 insertions(+), 96329 deletions(-)
For an detailed overview of the changes see the New And Noteworthy Document. Among the highlights are:
- Usage of C++11 STL instead of custom containers where possible
- Reduced Memory consumption of core classes
SceneLoaderManager API to load scenes files
- OgreMain is now independent of platform UI libraries like Cocoa or X11
- Standard OgreScript syntax for overlay scripts
For an overview of the bugfixes, see the v1.10.12 changelog.
We started removing the API deprecated in 1.10 with this release and together with the architectural improvements it means that your code might not compile any more. However we tried to keep API changes as non-invasive as possible. For an example of the expected changes to be made, take a look at this (backwards-compatible) diff on Ogitor.
We are keeping the time based release model for the 1.x branch. This means that you can expect OGRE 1.12 in April 2019.
We would like to thank everyone who helped us make this release possible. The following list shows a list of contributors for 1.11 based on the git logs:
Pavel Rojtberg, Eugene Golushkov, Jean-Baptiste Griffo, Dmytro Yunchyk, SNiLD, Matías N. Goldberg, Erik Ogenvik, SerVerXPlanet, Florian Schoppmann, Marko Tsengov, Transporter, Christopher Christensen, Kolia P., Long Cheng, Peter Westerström, Bohdan Kornienko, Flavien Bridault, Tobias Schmidt, Naoto Kondo, Tim Rakowski, William Woodall, kPYKx7Ddw4n1aIKZ, Andreas Greimel, Bastien Bourineau, Dominik Frizel, Jack Stocker, Lior Lahav, Martin Idel, Raffaele Bratta, Sebastian Bugiu, Simon Hyll, Tobias Kunicke, Vlad Stoyanov, Feiyun Wang, majic79, xissburg
If you are currently deep in the development cycle using 1.10.11 and do not want any disruptions, I have good news for you: relevant bug-fix only commits were cherry-picked from master (1.11) to 1.10.11 and accumulated in the 1.10.12 release, which you can find here.
During the period of Feb 7. – March 7. we received 117 replies. At the same time the ogre 1.10 Windows SDK alone was downloaded 5161 times. So while the results are significant, they are probably not representative.
The average Ogre application is a Game displaying Overlays and Particles. It was written as a Hobby in C++ and targets Windows 10 using OpenGL.
As you see statistics are lies, so better take a look at the actual numbers yourself.
To spare you reading all the free-form answers though, here is a summary
Most severe drawbacks of Ogre 1.10
- lack of documentation (8x)
- Difficult to build/ setup (6x)
- code quality/ readability (5x)
- outdated documentation (4x)
- Performance (4x)
- Compositor Component (2x)
- no/ bad scene editor (2x)
- diverging 1.x and 2.x branches (2x)
- lack of art/ asset pipeline (2x)
- Abandoned Plugins (2x)
- “next-gen” graphics (1x)
Most important future change for Ogre 1.11
- modern rendering techniques (8x)
- Keeping code stable (7x)
- Archive out of date documentation (2x)
- more support for existing Addons/ Plugins (2x)
- simplify SCM (2x)
- C++11 Support (2x)
- VR & Stereo Rendering (1x)
As you can see some of the requests are contradicting and some are only vague, like “next-gen graphics”.
To others I wrote a short reply here.
To streamline the development process & discussion of Ogre 1.x, we now have the Ogre evolution proposals.
Basically it consists of a structured textual specification similar to the Python PEPs. Click on the link above to learn more.
Those of you who have been around Ogre for some time might remember that back in 2011, we conducted a survey about our user base. The results of which can be found here.
As we have started the 1.11 development cycle we would like to assess to correctly emphasize the development and ideally drop some barely used features that will free resources for more important things.
So for the next four weeks until the 7th of March, you have the chance to participate and help us to get an impression about our user base, how Ogre is used and share some wishes for the future. Simply follow the link and make your way through the 11 questions. It should not take up much time since most of the questions are simple checkbox or radio button questions.
Link to survey
We want to thank you all upfront for helping us to develop Ogre further and getting some valuable insight information about the people using the engine!
PS: We would be glad if you could spread the word about the survey via all available channels to all potential Ogre users, because: The more participants, the more accurate are the results of course.
The 1.10.11 release marks the final (planned) release for the 1.10 series and kicks off the 1.11 cycle that will allow us to break the API. As announced in the mid-term report we will use this to move to C++11 and drop some of the deprecated functionality.
But the 1.10.11 release has also some highlights on its own, namely
Today we want to highlight one of the many games based on Ogre3D that have come out recently. This time: iUBES:2
We asked the team behind the game if they could share some insights into the Ogre3D usage and how the game was built in general, and codrer was kind enough to provide those:
- iUBES was developed using Visual Studio Express + Ogre 1.9 ; I didn’t upgraded simply because everything was running perfectly fine, without any need for additional power. Even if I’m looking forward to try out Ogre 2.x in the near future.
- From my point of view, one of the main advantage of using Ogre engine is that it doesn’t carry any overweight. For this indie / somehow minimalistic design, it’d be a shame to ask for consequent configuration: Ogre helps iUBES running on almost any low-end laptop (DX9/ XP/ integrated graphics…).
- At this time I only released a Windows/DX9 version of the game. However, beta testers proved the game to be running perfectly through Play On Linux / Play On Mac steam emulation. I was quite surprised actually.
- No change have been made to Ogre, the game simply dynamically links to ogre’s dll right from the SDK. I only had to use my own functions for a couple of optimizations like math (hundreds of units bouncing on a spherical ground consume a lot of trigonometry), strings functions, … those kind of small things.
- I didn’t use further libraries than Ogre itself. I even decided at some point to discard OIS (I feel more confortable using windows API directly). Everything else (GUI, winsock, directsound…) has been written from scratch for maximum flexibility.
- Again that’s one of the things I DO love with Ogre: this is a pure rendering engine which doesn’t mix unrelated things like most game engines do. We can create our very own setup.
- Except from trees and the iubes themselves which are very low-poly assets created using 3DS, the world is entirely procedural. Ogre’s ManualObject class was a huge friend.
- As each building is build up bloc per bloc (hundreds), Ogre’s convertToMesh() method could have been a bottleneck. Hence each construction is split between a couple of meshes, then piled up and revamped from time to time during runtime.
- Apart from water which use a classic 2.0 fragment shader, all the other textures are using the fixed pipeline. Terrain and Constructions use VertexColourTracking plus modulative detail textures. Since meshes are built procedurally, vertex colours have major benefits here (using basic math to finely darken inner faces of a building to improve lighting, and so on).
- Fun fact: while I use PSSM hand written shadows on other projets, for this game I switched back to… built-in Ogre shadows (i.e. SHADOWTYPE_TEXTURE_MODULATIVE). Apart from some very little glitches, it fits quite perfectly my spherical world!
- At this point I may confess that I’m a huge fan of the K.I.S.S. principle…
- At the end of the day, this game only uses a fragment of Ogre’s capabilities, but benefits utterly from its versatility. “Hey let’s make a procedural RTS online game in a spherical world” – for such a custom idea, Ogre was the obvious way to go.
You can see more videos and screenshots on Steam where you of course can also purchase the game.
If you too want a spot on the news for your Ogre powered application, then you can e-mail us at .