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
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
// just do normal rendering
// execute compute shaders post-render
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.
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).
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;
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.
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(-)
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.
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.