With the 1.10.8 release, the 1.10 support cycle is approximately half way over, which is a good time to recap the features and switches that got introduced since the initial release.
Note that Ogre 1.10 is the only actively maintained release – all other branches have reached their end of life, so no bugfixes will be back-ported.
If you are still using Ogre 1.9 or even a previous release, you are encouraged to upgrade to 1.10.
But besides bugfixes, there were also some notable changes, which will be presented below.
Following the Python Component that got introduced with the initial 1.10 release, we now introduce the Java Component. Both of them share the same SWIG definitions, meaning they have the same API coverage.
The existing Vertex Array Object (VAO) implementation in GL3+ and GLES2 was so broken that VAOs had to be updated each frame – essentially disabling them. From 1.10.7 on VAOs work as expected and give a performance boost of about 10%.
Thanks to a contribution by Jean-Baptiste Griffo the GL3+ RenderSystem got a StateCache (accompanying GLES2 and GL). We took it as a starting point to further improve and unify the State Cache implementations and indeed could eliminate various bugs inside the GLES2 and GL caches.
Deprecation of node-less positioning
Traditionally Ogre allowed you to place Cameras and Lights in the scene without attaching them to a SceneNode. This resulted in three different positioning APIs for Cameras, Lights and SceneNodes with slight inconsistencies (
SceneNode::translate) and one big one:
- SceneNodes & Cameras look into (0,0,-1) by default
- whereas Lights look into (0,0,1)
To make things consistent, using the Camera and Light API for positioning is deprecated now. If you want to move away from the origin, you have to attach to a SceneNode (same as you would have to with Ogre 2.x).
The only exception is
Light::setDirection, which you should call with (0,0,-1) to make Lights behave like the other Nodes.
We cannot go ahead and change the default direction for 1.10 as it would break existing applications.
Compile time switches
Lets turn to some more fundamental changes that change the API and thus are hidden behind CMake switches.
OGRE_THREAD_SUPPORT == 3
To quote Steve, who initially implemented threading in Ogre:
OGRE_THREAD_SUPPORT==1 where resource management is fully threaded, was hopelessly naive. It required too many locks, and also that the rendersystem was multi-threaded.
OGRE_THREAD_SUPPORT==2 improved that by not requiring that the rendersystem was threaded, and just doing disk I/O in the background, but still, the whole process is still driven within the Resource class, which means the locks are still in place on Resource and by association SharedPtr and a bunch of other classes too.
Therefore we introduce the new
option. Setting this, Ogre core objects – most notably Resource – are not thread-safe. However the DefaultWorkQueue is
threaded. This allows the Terrain and MeshLOD Components to be multi-threaded without the locking overhead in OgreMain. See #454 for details
Setting this option, the custom
AtomicScalar types become merely aliases for
std::atomic which are both more portable and higher performance alternatives.
std::thread is used as the default threading provider.
Traditionally Ogre uses (hash-)maps to store everything by name, including sub-nodes and attached MovableObjects. While this gives you
O(log(N)) lookup, iteration performance is terrible as maps are spread all over the memory and thus trash the CPU caches.
However with rendering the most common operation is iterating (for e.g culling) over all children while lookup is only done for changing the state. Furthermore high-frequency lookups can be easily avoided by just storing the returned pointer.
will use the cache friendly
instead of maps. Naturally lookup by name becomes
and the API changes. However this improves rendering performance by about 20% – bringing Ogre 1.x into 2.0 range when only a few nodes need updates. See #440 for details
An outlook on Ogre 1.11
As the amount of possible configurations explodes with each switch we introduce, we are going to only allow one setting with Ogre 1.11 to keep things maintainable.
So rather think about the switches in terms of feature previews and not so much as options.
With Ogre 1.11 we will choose the following configuration:
OGRE_USE_STD11=ON will be supported. In other words Ogre will switch to C++11.
OGRE_NODE_STORAGE_LEGACY=OFF will be supported.
OGRE_THREAD_SUPPORT=3 will be the default. Only the
std::thread provider will be supported.
- OGRE_RESOURCEMANAGER_STRICT=ON will be the default.
- Default Lights direction will be (0,0,-1).
- Lots of the deprecated API will be dropped – better start looking at the deprecation warnings now.
- Custom memory allocators will no longer be supported. You will be able to define C++11 template aliases to set them for STL containers though.
At this year’s Web3D conference in Brisbane a new Ogre based X3D viewer, called x3ogre, was presented.
X3D is an ISO specified file format for 3D file transmission and interchange which is now natively available to Ogre.
The Web3D is a scientific conference concerning technologies like WebGL, X3D and glTF.
The presented viewer is called x3ogre and provides a layer for loading and manipulating X3D files inside Ogre.
Vice versa the Ogre Material and Mesh formats also become accessible inside X3D files.
To put the viewer on the Web the x3ogre leverages Emscripten and the GLES2 RenderSystem to get translated to WebGL2 and WebAssembly.
The MIT licensed implementation is available on github.
We finally tagged the Ogre 1.10 branch as stable (tag: v1-10-4), 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 more than 3 years of work from various contributors when compared to the previous 1.9 release. Notably, it includes the following three GSoC 2013 projects:
The ResourceManager redesign GSoC was superceded by the strict mode CMake switch.
Enabling the strict mode is highly recommended, however the default is legacy mode to ensure compatibility with existing projects.
Additionally it includes the changes from the git fork that got merged back into default. The fork formally did the 1.10.0 release, thats how we ended up with 1.10.4 here.
Currently we don’t have any published SDKs yet, since we still rely on team and community members to help with the building and packaging process and that takes some time of course. We will update the download page as they become available and also try to update the announcement thread in the forums.
For an detailed overview of the new features see the New And Noteworthy Document. Among the highlights are:
- Python bindings as a component
- vastly improved GL3+/ GLES2 renderers with GL3+ now being the recommended choice on *nix systems
- Bites Component for rapid prototyping of applications
- Emscripten platform target – supporting Web Assembly & WebGL2
- improved build system, automatically fetching all required dependencies.
- A new HLMS Component implementing physically based shading
- Unified Documentation: the API docs, the manual and some Wiki pages have been merged and are now managed with Doxygen. As a consequence, the Wiki is outdated when it comes to OGRE 1.10. If you find something particularly missing, feel free to submit an additional tutorial.
Despite the amount of new features OGRE 1.10 provides the smoothest upgrade experience between OGRE releases so far. See the API/ ABI change overview for OGRE 1.7 – 1.10 that is kindly provided by ABI-laboratory.
Note that some components are marked as
[BETA]. This does not mean that they are likely to crash, but that we can not give any API stability guarantees for them right now. You should expect their API to change without a deprecation period while we we iron the warts out as the Component get more exposure.
In turn for the core components, our deprecation list has grown considerably. You can keep using these APIs for now, as we intend to support them until OGRE 1.11. Speaking of which; to make OGRE releases predictable, we will switch away to a feature based to a time based release model for the 1.x branch. This means that you can expect OGRE 1.11 in April 2018.
We would like to thank everyone who helped us make this release possible. The following list shows a list of contributors for 1.10 based on the git logs:
Pavel Rojtberg, Eugene Golushkov, David Rogers, Jesse Johnson, Murat Sari, Lior Lahav, Peter Szücs, Philip Allgaier, Matías N. Goldberg, Sasu Robert, Assaf Raman, Jannik Heller, lunkhound, Juan Borda, Daniel K. O., Jan Drabner, Transporter, Ahmed Allam, Flavien Bridault, Lf3T-Hn4D, J. Edward Sanchez, Mattan Furst, Shenjoku, arkeon, nxgraphics, 0xc0deface, Alexpux, Caleb Bartholomew, Christian Refvik, Harald Reingruber, Stefania Pedrazzi, Unknown, ja0335, threax, Al Reay, Andrew Piper, BAntDit-PC\BAntDit, Bastian Köcher, David Reepmeyer, Inifinity, Joel Croteau, Tomáš Kováč, tangren, Arroy One, Charles Prévot, Chris Burns, Daniel Brall, Daniel Gouvêa, Jean-François Verdon, Joël Lamotte, Matthew Fletcher, Misha, Oleksiy Ivanov, Simon Willshire, al2950, xantares, Alex Peterson, Alexey Knyshev, Andrew Fenn, Arroy, Bruno Sanches, Carsten, Crashy, Dainius Vaiksnys, David Avedissian, Denis CARLUS, Francesco Guastella, Gauthier POGAM–LE MONTAGNER, Glenn Ramsey, Holger Frydrych, J W, James Chen, Joe Brown, Justin Grant, KoenMertens, KungFooMasta, Mako_energy, Marcin Juszkiewicz, Michaël Broutin, Osamu Takasugi, Richard Plangger, Robert Hildebrandt, Robin Norrman, Ryan Thoryk, SNiLD, Sam Hocevar, Steve Peters, TheOnlyJoey, Ziriax, emilie.harquel, mkultra333, philiplb
BTW: if you want to contribute to OGRE, you can now use github as well.