Ogre 1.12.9 was just released. Typically we do not write a specific announcement for minor updates, however this one contains some major new features that warrant this one.
Multi Language GPU Programs
As noted in the last progress report, even when using OgreUnifiedShader.h one had to duplicate the GpuProgram definitions in the Ogre .material files. This has been fixed in master by allowing multi-language programs to be defined like
The separate ogre-assimp project was merged into the main repository as the Codec_Assimp Plugin, which allows loading arbitrary meshes and runtime and the OgreAssimpConverter Tool for converting meshes to the Ogre .mesh format offline (which improves loading time).
Especially the introduction of Codec_Assimp is notable, as mesh loading now goes through the same Codec dispatching as image formats.
On the application side, you can then just call sceneManager->createEntity("Bike.obj") like I did in OgreMeshViewer below:
so simply loading Codec_Assimp turned that into a general-purpose mesh-viewer.
Descriptive Hardware Buffer Usage
Did you ever wonder whether your buffer usage is rather static or rather dynamic? Well at least I did as these rather abstract names do not tell you much what it means in terms of memory allocation – but wonder no more! There are now new, actually descriptive, aliases:
Old Name
New descriptive alias
HBU_STATIC_WRITE_ONLY
HBU_GPU_ONLY
HBU_DYNAMIC_WRITE_ONLY
HBU_CPU_TO_GPU
HBU_STATIC
HBU_GPU_TO_CPU
HBU_DYNAMIC
HBU_CPU_ONLY
So while previously you were told to use HBU_STATIC_WRITE_ONLY, you now immediately see that the buffer will end up in GPU memory. Likewise, if you use the DYNAMIC variant, the buffer will be optimized for recurrent CPU writes.
I came up with those when planning the Vulkan RenderSystem backport and those are actually borrowed from the Vulkan Memory Allocator library. There you can also find all the subtleties regarding Vulkan, that I did not bother copying to the Ogre manual.
While these flags were named with Vulkan in mind, they map surprisingly well to the Ogre ones and, most importantly, to the actual Ogre usage. After refining the meaning, it allowed dropping several superficial copies and readbacks in the D3D11 & D3D9 RenderSystems. Yes, these even map well to D3D9.
Super-fast debug drawing
Debug drawing in Ogre has been refactored and is now abstracted by the DebugDrawer API with a DefaultDebugDrawer implementation.
One advantage of this is that debug drawing code will not be sprayed across core classes. At least with 1.13 – for now we keep things as is not to break any obscure use-cases.
The main advantage however is, that debug drawing is now properly batched – whereas there was one draw-call per WireBox previously, there is now one draw-call for all wireboxes in the scene. This is also true for coordinate crosses and camera frustums.
Other highlights
Ogre can now be built using the latest Emscripten SDK, thaks to a contribution by Gustavo Branco
The Config dialog on Windows & Linux was updated to use the new Ogre logo
The Metal RenderSystem backport from Ogre-next, that I talked about in the last round-up, now has landed in the master branch and will be available with Ogre 1.12.7. See the screenshot below for the SampleBrowser running on Metal
Sample Browser running with Metal on OSX
The current implementation pretends to have Fixed Function capabilities. Leveraging the unified FFP API introduced with the initial 1.12 release, this allows operating with a default shader. This shader only supports using a single 2D texture without lighting. E.g. vertex color is not supported. This is why the text is white instead of black in the screenshot above.
Proper lighting and texturing support, requires a Metal Shader Language support in the RTSS, which is not there yet. However, if you are mainly using custom shaders on OSX, you can start experimenting with Metal now. Furthermore, buffer updates are currently slowish, as staging buffers had to be disabled. Therefore, the Metal RenderSystem is tagged as EXPERIMENTAL.
Further development will happen at a lower pace though, as Metal neither has the large prevalence of D3D11 nor gives the synergy effects across platforms we have with OpenGL.
So if you want full Metal support in Ogre1, consider contributing and fixing bugs. The code was simplified during backporting, which shows by the size reduction from 14k loc in v2.1 to 9k loc that are now in Ogre1.
While there have been snippets to provide Ogre integration with Qt for a long time, there is now an officially provided version in master and scheduled for Ogre 1.12.6.
This integration requires Qt5 and builds upon the ApplicationContext abstraction living in OgreBites which already handles SDL2 windowing and Activities on Android. In contrast to previous attempts this means that it does not follow the “QtOgreWidget approach”. This might sound less convenient, but is necessary to properly handle multiple Ogre Windows or Ogre Views. Also it should be familiar for everybody who is using the QApplication API.
The implementation lives in a separate libOgreBitesQt.so library which is only created when Qt is detected when building – so if you do not use it, you do not have to care about Qt dependencies.
The API is designed to be a drop-in replacement for ApplicationContext. This means that you can just take the setup tutorial, but use the ApplicationContextQt instead and your app will be Qt5 based. Also, because of the Input event abstraction we did for Ogre 1.11.0, the CameraMan and Trays code will continue working – just like the Event forwarding to ImGui.
Furthermore, I have ensured that the API also fits when the Qt Event loop is used and adapts to existing projects. For this, I have ported ogitor and spacescape to the new API. Notably, with spacescape the Ogre view is now only redrawn on-demand when things change (e.g. settings, window resize).
The exposed API is QWindow based making it lightweight as only the QtGui module is required. Also this should allow extending it for QtQuick in the future, which is also QWindow based.
I just published the Ogre 1.12.4 holiday release. Besides wishing you all a merry Christmas, there are new features that deserve an in-depth description.
OGRE_NODELESS_POSITIONING
Using Cameras and Lights without having them attached to a SceneNode was already deprecated with the 1.10 release and you got compiler warnings if you attempted to so since then.
With the OGRE_NODELESS_POSITIONING=OFF build option, we now allow actually taking advantage of having the positioning code in the Nodes.
With this option all positioning code in Cameras and Lights will be disabled, which results in faster updates and notably smaller memory footprint, which is
12% less for Lights
7% less for Cameras
As the node-less positioning API will be gone as well, you should make sure that you trigger no warnings in this regard.
For the most part the porting should look like
// before
mLight->setDirection(...);
// after
mSceneMgr->getRootSceneNode()->createChildSceneNode()->attachObject(mLight);
mLight->getParentSceneNode()->setDirection(..., Node::TS_WORLD);
Also refer to the notes on the deprecation page. Some additional caveats to look out are:
SceneNodes do not use a fixed yaw axis, while Cameras do
SceneNode::setDirection uses TS_LOCAL by default while Cameras and Lights behaved like TS_WORLD
Background shader compilation
The GpuProgram code got refactored and now properly respects the prepare and load states. This means that the shaders can be loaded and pre-processed in a background thread.
With D3D this additionally allows compiling the shaders in the background, which is quite handy given that HLSL compilation times range in the order of seconds.
You probably are thinking “This is great and all, but how to do background resource loading in Ogre?”. Given that was a common question for years, there is finally an according tutorial.
compilation with OGRE_CONFIG_DOUBLE=TRUE works again
The built-in shadow Renderer now correctly handles multiple shadow casting lights with the RTSS
The RTSS now fully supports linear skinning and Dual Quaternion skinning with shearing (GLSL, GLSLES and HLSL). The manual was updated for the available options.
Hardware skinning and multiple shadows via the RTSS
Ogre 1.12.3 was just released. Typically we do not write a specific announcement for minor updates, however this one contains some major new features that warrant this one.
Of course there is the usual slew of bug-fixes as well, which are listed here.
Ogre 1.12.9 was just released. Typically we do not write a specific announcement for minor updates, however this one contains some major new features that warrant this one.
