following the last post about what is going on around Ogre, here is another update. With the Ogre 1.12.12 release, mainly the usability of Ogre was improved with the following additions.

Ogre 1.12.12 release

The last 1.12 release had some serious regressions in D3D9 and GL1, therefore I scheduled one more release in the 1.12.x series.

Updated release notes

As the Ogre 1.12 series was an LTS release, many important features landed after the initial 1.12.0 release. To take this into account and to give an overview which version you need, the “New and Noteworthy” document was updated with the post .0 additions. (search for “12.” to quickly skim through them).

Nevertheless, there are also some new features in the 1.12.12 release itself:

Cubemap support in compositors

Compositors render targets can now be cubemaps by adding the cubic keyword to the texture declaration – just like with material texture_units.

To really take advantage of this, you can now also specify the camera to use when doing render_scene passes. This way any camera in your scene can be used as an environment-probe for cube mapping.

Finally, to really avoid touching any C++, there is now the align_to_face keyword which automatically orients the given camera to point to the targeted cubemap face.

See this commit on how these things can simplify your code and this for further documentation.

Terrain Component in Bindings

Thanks to a contribution by Natan Fernandes there is now initial support of the Terrain Component in our C#/ Java/ Python bindings.

Python SDK as PIP package

Python programmers can now obtain a Ogre SDK directly from PyPI as they are used to with:

pip install ogre-python

Just as the MSVC and Android SDKs, it includes the assimp plugin which allows to load almost any mesh format and ImGui, so you can create a UI in a breeze.
For now only Python 3.8 is covered – but on all platforms. This means you can now have a pre-compiled package for OSX and Linux too.

Improved blender2ogre

Thanks to some great work by Guillermo “sercero” Ojea Quintana, the blender2ogre export settings are much more user friendly now:

On top of having some context what a option might do, the exporter can now also let Ogre generate the LOD levels. This gives you the choice to

  • Iteratively apply blender “decimate” as in previous releases. This will generate one .mesh file per LOD level, but may result in a visually better LOD
  • use the Ogre MeshLOD Component. This will store all LOD levels in one .mesh file, only creating a separate index-buffer per LOD. This will greatly reduce storage compare to the above method.

SceneNode animations

But he did not stop there, blender2ogre now also exports NodeAnimationTrack based animations. To this end it follows the format introduced by EasyOgreExporter, so both exporters are compatible to each other.

To formalise this, he even extended the .scene type definition, so other exporters implementing this function can validate their output.

Needless to say, he also extended the DotScene Plugin shipped with 1.12.12 to actually load these animations.

.scene support in ogre-meshviewer

Picking up the work by Guillermo, I exteded ogre-meshviewer to load .scene file – in addition to .mesh files and whatever formats assimp knows about.

However, for now it will merely display the scene – there are no inspection tools yet.