It’s been 2 years since 2.3.0 and almost a year since the last 2.3.x release. It’s about time for 3.0.0!

Ogre to OgreNext name migration

We’re trying to make OgreNext and Ogre able to be installed side-by-side. The details can be found in the manual.
But the short version is that we’re moving forward to have Ogre.dll and OgreNext.dll as different DLLs so that
Ogre and OgreNext can coexist for projects who want to support both, and for Linux distros that want to support
both without getting into name clashes.

Given that this requires changes in client projects (e.g. CMakeLists.txt and *.sln, etc) that depend on OgreNext,
the old naming can be selected using the CMake variable OGRE_USE_NEW_PROJECT_NAME which defaults to OFF for 3.0, but will default to ON for 4.0; and will be scheduled for removal in OgreNext 5.0.

Dealing with ABI mismatches: AbiCookie

A common problem in our community are crashes that were caused by simple mistakes such as mixing OgreNext.dll (Release) with OgreNext.dll (Debug). Or upgrading to a newer version of OgreNext but a lingering old DLL got loaded instead.

This can cause quite cryptic errors and crashes our users were having trouble to deal with.

AbiCookie is here to fix most of this issues, as it validates on load that the DLL being loaded matches the one it is supposed to be linked against.

The ABI cookie is used like this during Ogre::Root creation:

const Ogre::AbiCookie abiCookie = Ogre::generateAbiCookie();
mRoot = OGRE_NEW Ogre::Root( &abiCookie, pluginsPath, cfgPath,
                         mWriteAccessFolder + "Ogre.log", windowTitle );

While the AbiCookie may not catch all sort of ABI mismatches, it should catch the most common mistakes.
Plugins are also always validated by the AbiCookie.

ABI Semver

Starting 3.0.0; OgreNext will follow a modified semver versioning, where 3.0.x increments must absolutely not break the ABI, but 3.x.0 MIGHT be allowed to break the ABI in subtle changes. See this ticket comment for an explanation.

For this reason, most development will focus on 4.x.x; with 3.0.x for small fixes. Changes that would involve a 3.x.0 change will mostly be considered upon contract request.

Move to C++11 and general cleanup

The biggest focus of Ogre-Next 3.0.0 was easier maintenance and porting to newer versions; rather than new features.

We started aggressively using C++11’s override keyword, which makes much easier to catch derived classes whose functions have changed slightly in signature at compile-time.

We are also enforcing clang-format through CI to ensure code formatting stays consistent across the project and contributors.

Another important factor is that we fixed all warnings (or most, depending on your compiler version) in OgreNext.
Now compiling OgreNext results in a clean log. This results in a more robust codebase.

Furthermore, including headers no longer generates warnings in client applications, which is unacceptable.

This is not to say all changes were coding-style and C++ version related.

Particularly there have been PBR/PBS changes to better match what other engines are doing, with compatibility functions to restore the old look.

Towards the future: Ogre-Next 4.0

Actually Ogre-Next 4.0 is far more exciting! Development started a year ago as 3.0.0 stabilized and 4.0 has already interesting features:

Multithreaded Shader Compilation and PSO generation: This greatly speeds up shader compilation, app loading and greatly reduces stutter. Available for Vulkan and Metal.
ParticleFX2 plugin: An alternate plugin for ParticleFX2 with a focus on performance (parallel CPU simulation + vertex-shader-based geometry generation). The original ParticleFX plugin will not be deprecated as it serves different means. Certain FXs are easier to perform with the original PFX, while PFX2 focus on performance for large amount of particles and special rendering features.
Alpha Hashing and Alpha Hashing with A2C (Alpha to Coverage): A very decent trick that gets impressive results to perform transparency with depth writes enabled, which means it’s Order Independent (unlike traditional alpha blending).

About the 3.0.0 release

For porting information see:

For a full list of changes see the Github release.

Source and SDK is in the download page.

Discussion in forum thread.

Thank you to everyone involved (see Github release) in making this release possible.