The 1.11.5 release marks the final (planned) release for the 1.11 series and kicks off the 1.12 cycle that will allow us to break the API. As announced in the mid-term report we will drop some of the deprecated functionality.
But the 1.11.5 release has also some highlights on its own, namely
With the Ogre 1.11.3 release, the 1.11 support cycle is half way over, which is a good time to recap the features and switches that got introduced since the initial release.
Good time to Contribute
If you are porting your Code to Ogre 1.11 now and find that you have local changes, it is a good time to create a pull-request and contribute them upstream.
Scape got substantially improved by Tobias Schmidt. Now all tools and import/ export work.
ogre-assimp got fixes for Texture exporting with 1.11 and proper normal handling.
ogre-video got updated for 1.11 and is now the recommended video plugin.
Overview
But lets turn to the new features now. Specifically:
Sampler Objects
Improved Compositors
Templated Vector
Unified Documentation
Sampler Objects
We started adapting the internal RenderSystem API to how modern graphics APIs like Vulkan or Gallium3D work by introducing ColourBlendState and Sampler Objects.
Sampler Objects are Script-User visible and therefore we will describe them in more detail. Essentially they store all parameters controlling how Texture data is fetched. Previously those were scattered around TextureUnitState (TUS).
Now you have separate, named Objects that are created by the TextureManager. This allows you to quickly change the settings for all associated Textures. Typically you have many Textures but only a few sampling states in your application.
We also use this mechanism inside Ogre to providing a DefaultSampler object which is shared by all TextureUnitStates. Calling MaterialManager::setDefaultTextureFiltering now simply modifies this DefaultSampler. If you modify one of the sampler parameters via the existing TUS API, we transparently create a new Sampler for this Unit – which results in a much cleaner implementation compared to the various flags used before.
Note that this script will work across all RenderSystems as the (GLSL/ HLSL) shaders will be auto-generated.
Additionally there is now a new “compute” compositor pass for explicitly dispatching compute shaders
compositor Compute
{
technique
{
target_output
{
// just do normal rendering
input previous
// execute compute shaders post-render
pass compute
{
material Compute/Compositor
thread_groups 16 16 1
}
}
}
}
where the Compute/Compositor material has one or more compute only passes, which can access any of the global auto-constants. Note that binding textures for UAV read/ write is not yet possible through scripts yet.
Templated Vector
Vector2, Vector3 and Vector4 are now just typdefs of the Vector<N, type> template. (e.g. Vector3 is Vector<3, Real>)
This allows you to use custom Vector types and is the first step to combat the Real type abuse in the code-base; initially the Real typedef was introduced as a configuration option for SceneNode calculations with double precision.
However at some point Real started to be used instead of float everywhere, but for most part the type must be float and not double. E.g. meshes are always stored at float precision as most RenderSystems did not support it double precision. Therefore all code interacting with meshes should work on floats exclusively (sparing some dot operations with large numbers).
New features will still land in 1.11.x point releases, so the 1.12.0 will be just the last 1.11 without some deprecated features (just as 1.11.0 was compared to 1.10.12).
Therefore this is mainly to inform you about the API breakage coming with 1.12, which currently is
bump required OpenGL version for GL3+ to 3.3
remove some of the dragging deprecated API. (including script parameters)
Probably the biggest strength of Ogre 1.x is the legacy of content creation tools and addons. At this, the tools promoted at OGRECave were updated to work with 1.11 / strict resource lookup.
Here the ogre-ffmpeg-videoplayer was dropped and replaced by the ogre-video plugin (aka TheoraVideoSystem) due to small footprint and better Ogre interop.
Furthermore there are two notable additions;
Spacescape
This is a tool for creating procedural space skyboxes with stars and nebulas using the layer pardigm known from most graphics programs:
Getting it running with 1.11 only required minimal porting and importing/ exporting is fully functional.
This is a procedural terrain editor with different brushes, some of which are implemented on the GPU.
Unfortunately this tool used and outdated version of wxWidgets for its UI, which is hard to come by nowadays. However Jacob Moen (jacmoe) did an initial port to Qt5 some time ago.
Building upon this work, it was just a matter of throwing away OIS and some minor updates to standard C++ to get it up and running.
While you can already paint terrains, many features are still missing. Most notably actually exporting the resulting heightmap. So if you toy around with it, consider contributing some patches.
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.
Changes
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(-)
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.
Contributors
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
Ogre 1.10.12
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.
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.