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.
The 1.12.6 point release kept its focus on integration. Notably, it ships the Qt OgreBites implementation, that was discussed in the previous post. Also there are the following notable changes:
The OSX & iOS support was vastly improved. If you had any issues with using Ogre in these enviroments, please try again with Ogre 1.12.6. The improvements include scaling the input events along the window content scaling and corrected library resolution from inside an .app bundle. I also started backporting the Metal RenderSystem to the 1.x series. See the metal-wip branch. Help is welcome.
Also Ogre 1.12 is now available in Debian sid & unstable. Notably, this also covers the python bindings and imgui. So prototyping a 3D application is only a apt install python3-ogre-1.12 away. Also this is a major step forward from the previous Ogre 1.9 package and allows 3rd party apps like ROS relying on it. These packges are also availble in the latest Ubuntu 20.04 release, which is based off Debian unstable.
Next, the MSVC SDK was refined: it now properly packages and compiles the C# ibindings. You no longer have to compile any Ogre C# sources yourself. As for C++, the pdb files are finally included, which allows you using the SDK for debugging (note that the build type still is RelWithDebInfo and not Debug).
The refined “Fixed Pipeline Enabled” RenderSystem option allows you to bring the legacy GL & D3D9 RenderSystems into a programmable pipeline only mode. Setting it to false is the first step, if you consider porting to GL3+ & D3D11 as it will enable the RTSS shader generation, while keeping everything else the same. It also allows you toggling forth and back between shader based and fixed pipeline to compare rendering, instead of having to pull the plug once and for all.
Probably the biggest strength of Ogre 1.x is the legacy of content creation tools and addons. Here, I resurrected the following tools beneath the OGRECave umbrella:
The meshmagick CLI .mesh optimization and manipulation tool. It allows you to conveniently change the coordinate system or merge all sub-meshes into one buffer.
The shiny shader meta-compiler & management library. In the mid-term we want to extend the RTSS by similar features and generally recommend to prefer the RTSS. However, there are some existing projects relying on this library, and this allows them to upgrade to recent Ogre releases.
The ogre-gpgpu toolkit. This is a collection of many Computer Vision and Augmented Reality related tools built around Ogre. So far, I only brought back the Ogre-CUDA bridge. When it is ready, this probably will be moved into the core repository. Therefore, this project can be considered as a staging area.
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.
During the period of Feb 29. – March 31. we received 47 replies. At the same time the ogre 1.12.5 Windows SDK alone was downloaded 437 times. So while the results are significant, they are probably not representative.
The most interesting result is probably this
When considering the boosted votes of the patreon supporters, the enterprise and enthusiasts parts increase. Still, the enterprise fraction remains dominant.
Those of you who have been around Ogre for some time might remember that back in 2018, we conducted a survey about our user base. The results of which can be found here.
For the 1.13 development cycle we would like to assess to correctly emphasize the development on the most used features.
So for the next four weeks until the 29th of March, you have the chance to participate and help us to get an impression about our user base, how Ogre is used and share some wishes for the future. Simply follow the link and make your way through the 13 questions. It should not take up much time since most of the questions are simple checkbox or radio button questions.
We want to thank you all upfront for helping us to develop Ogre further and getting some valuable insight information about the people using the engine!
PS: We would be glad if you could spread the word about the survey via all available channels to all potential Ogre users, because: The more participants, the more accurate are the results of course.
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
