News

Ogre Ecosystem Roundup #2

following the last post about what is going on around Ogre, here is another update.

Ogre 1.11.1 point release

The 1.11 release got it first update. Here mostly the documentation and the integration was improved.

  • There is now a Working with Numpy tutorial and Building instructions on Doxygen.
  • Using a shared Ogre SDK on Windows got easier: relative paths in plugins.cfg are now resolved relative to the cfg instead of the binary.
  • Specifying a set of required Components in CMake is now full checked (e.g find_package(OGRE 1.11 REQUIRED COMPONENTS RTShaderSystem))
  • For the full list of changes and bugfixes as always consult the github release

Addons ported

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;

Spacescape

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.

get it at https://github.com/OGRECave/spacescape

Scape

This is a procedural terrain editor with different brushes, some of which are implemented on the GPU.

 

Unfortunately this tool used and outdated version of wxWidgets for its UI, which is hard to come by nowadays. However Jacob Moen (jacmoe) did an initial port to Qt5 some time ago.

Building upon this work, it was just a matter of throwing away OIS and some minor updates to standard C++ to get it up and running.

While you can already paint terrains, many features are still missing. Most notably actually exporting the resulting heightmap. So if you toy around with it, consider contributing some patches.

get it at https://github.com/OGRECave/scape

Ogre3D 1.11 released

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.

Changes

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(-)

For an detailed overview of the changes see the New And Noteworthy Document. Among the highlights are:

  • Usage of C++11 STL instead of custom containers where possible
  • Reduced Memory consumption of core classes
  • New SceneLoaderManager API to load scenes files
  • OgreMain is now independent of platform UI libraries like Cocoa or X11
  • Standard OgreScript syntax for overlay scripts

For an overview of the bugfixes, see the v1.10.12 changelog.

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.

Contributors

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

Ogre 1.10.12

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.

 

 

Ogre 1.10 User Survey Results

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.

As you see statistics are lies, so better take a look at the actual numbers yourself.

To spare you reading all the free-form answers though, here is a summary

Most severe drawbacks of Ogre 1.10

  • lack of documentation (8x)
  • Difficult to build/ setup (6x)
  • code quality/ readability (5x)
  • outdated documentation (4x)
  • Performance (4x)
  • Compositor Component (2x)
  • no/ bad scene editor (2x)
  • diverging 1.x and 2.x branches (2x)
  • lack of art/ asset pipeline (2x)
  • Abandoned Plugins (2x)
  • “next-gen” graphics (1x)

Most important future change for Ogre 1.11

  • modern rendering techniques (8x)
  • Keeping code stable (7x)
  • Archive out of date documentation (2x)
  • more support for existing Addons/ Plugins (2x)
  • simplify SCM (2x)
  • C++11 Support (2x)
  • VR & Stereo Rendering (1x)

 

As you can see some of the requests are contradicting and some are only vague, like “next-gen graphics”.

To others I wrote a short reply here.

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.

 

Ogre 1.10 User Survey 2018

Those of you who have been around Ogre for some time might remember that back in 2011, we conducted a survey about our user base. The results of which can be found here.

As we have started the 1.11 development cycle we would like to assess to correctly emphasize the development and ideally drop some barely used features that will free resources for more important things.

So for the next four weeks until the 7th 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 11 questions. It should not take up much time since most of the questions are simple checkbox or radio button questions.

Link to survey

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.

Ogre Progress Report: December 2017

Wow! It’s been a long time since the last report.

A lot has happened since last time, so I thought and was pressed to inform of what’s new. I (dark_sylinc) have been bugged by two people on Twitter to write this update, so you can thank them for this report!

But first of all, Merry Christmass and Happy New Year!!!

If you don’t celebrate any or all of the two, then have a great day anyway!

read more…

Game highlight – iUBES:2

Today we want to highlight one of the many games based on Ogre3D that have come out recently. This time: iUBES:2

We asked the team behind the game if they could share some insights into the Ogre3D usage and how the game was built in general, and codrer was kind enough to provide those:

  • iUBES was developed using Visual Studio Express + Ogre 1.9 ; I didn’t upgraded simply because everything was running perfectly fine, without any need for additional power. Even if I’m looking forward to try out Ogre 2.x in the near future.
  • From my point of view, one of the main advantage of using Ogre engine is that it doesn’t carry any overweight. For this indie / somehow minimalistic design, it’d be a shame to ask for consequent configuration: Ogre helps iUBES running on almost any low-end laptop (DX9/ XP/ integrated graphics…).
  • At this time I only released a Windows/DX9 version of the game. However, beta testers proved the game to be running perfectly through Play On Linux / Play On Mac steam emulation. I was quite surprised actually.
  • No change have been made to Ogre, the game simply dynamically links to ogre’s dll right from the SDK. I only had to use my own functions for a couple of optimizations like math (hundreds of units bouncing on a spherical ground consume a lot of trigonometry), strings functions, … those kind of small things.
  • I didn’t use further libraries than Ogre itself. I even decided at some point to discard OIS (I feel more confortable using windows API directly). Everything else (GUI, winsock, directsound…) has been written from scratch for maximum flexibility.
  • Again that’s one of the things I DO love with Ogre: this is a pure rendering engine which doesn’t mix unrelated things like most game engines do. We can create our very own setup.
  • Except from trees and the iubes themselves which are very low-poly assets created using 3DS, the world is entirely procedural. Ogre’s ManualObject class was a huge friend.
  • As each building is build up bloc per bloc (hundreds), Ogre’s convertToMesh() method could have been a bottleneck. Hence each construction is split between a couple of meshes, then piled up and revamped from time to time during runtime.
  • Apart from water which use a classic 2.0 fragment shader, all the other textures are using the fixed pipeline. Terrain and Constructions use VertexColourTracking plus modulative detail textures. Since meshes are built procedurally, vertex colours have major benefits here (using basic math to finely darken inner faces of a building to improve lighting, and so on).
  • Fun fact: while I use PSSM hand written shadows on other projets, for this game I switched back to… built-in Ogre shadows (i.e. SHADOWTYPE_TEXTURE_MODULATIVE). Apart from some very little glitches, it fits quite perfectly my spherical world!
  • At this point I may confess that I’m a huge fan of the K.I.S.S. principle…
  • At the end of the day, this game only uses a fragment of Ogre’s capabilities, but benefits utterly from its versatility. “Hey let’s make a procedural RTS online game in a spherical world” – for such a custom idea, Ogre was the obvious way to go.

You can see more videos and screenshots on Steam where you of course can also purchase the game.

If you too want a spot on the news for your Ogre powered application, then you can e-mail us at .

 

 

Ogre Ecosystem Roundup

Recently there were several updates around the Ogre infrastructure and ecosystem. This post will outline the highlights for you.

Ogre 1.10.9 released

While this is actually core, there were several updates that also improve the Ogre ecosystem. Maybe the most prominent one is that ApplicationContext will now fall back to the installed plugins.cfg and resources.cfg if it does not find any it the working directory (or any previously searched locations).

While this sounds trivial it means that your ApplicationContext based application will just run ™ – no need to worry about the RTSS resources or where the plugins are located. Ok, to load custom resources, still have to provide a resources.cfg, but in most cases you will not need a plugins.cfg. By default all enabled plugins will get loaded automatically.

Related to this change is the deprecation of SceneType enum (i.e. createSceneManger(ST_GENERIC)). Most of the time it only gave you the right SceneManager Plugin by chance. See this thread for details. Instead you are now supposed to call createSceneManger("DefaultSceneManager") or createSceneManger("OctreeSceneManager") explicitly.

Next, basic tutorials 1 & 2 were ported (thanks to Bohdan Kornienko) from the wiki to the new Doxygen documentation and to 1.10 (ApplicationContext). The code is no longer copy pasted into the page, but rather referenced from a real project that can be built and tested. Obviously the tutorial porting is an ongoing effort that you are invited to join.

Finally the -Wundef and -Wmissing-declarations warnings were enabled and fixed the code. These warnings help us ensuring that internal functions are correctly marked static and that our preprocessor branching is sane.

Of course there were many more changes. For the details – as usually – refer to the github tag.

 

Many addons ported

If you take a look at the OGRECave group on github, you will find many of the addons, that make up the Ogre ecosystem. The ones inside the group, were ported to 1.10. Due to the internal reorganization in 1.10, this allowed dropping lots (like lots) of code: e.g. FindOGRE.cmake and BaseApplication could be safely dropped.

But particularly, the documentation was regenerated and now even correctly references any external Ogre classes. Take a look:

You might notice that some information is outdated or find some typos. Take the chance and and create a pull-request on github. Most of this is just some markdown inside the according repository.

 

Ogre visualisation module in OpenCV

There have been Augmented Reality demos using OGRE and OpenCV for a long time. However the new Ogre Visualisation module, short ovis, provides a far better and easier integration. This allows you to write an AR demo in just 35 lines of code.

 

Webserver migrated

Regular visitors might have noticed some downtime of the Forums and the Wiki. This was due to the migration of our Webserver to Bytemark that are kindly providing us with free hosting. This was quite a leap forward as the old server was still running Ubuntu 12.04 with PHP software versioned at around that time. To me it is a miracle that the server still was under our control..

Anyway…the new server is now running Ubuntu 16.04 with automatic security updates. Furthermore we moved from phpbb 3.0.8 to phpbb 3.2.1 (~6 years advance) and tiki from 6.4 to tiki 15.5 (~5 years advance). Besides better security, this brings us responsive (mobile) pages and emoji support 🙂

Wiki deprecation and addonforums archival

The migration has shown some problems with our infrastructure though. We had an isolated addonforums phpbb instance where users had to register separately from the main forums. However only a few addons even had post from this year – let alone having responses. Therefore this instance was not migrated. Instead it was converted into a static archive.

Furthermore using a wiki for code is outdated by todays measures. It sits somewhere between Github, WordPress and Doxygen, where each of the alternatives offer a superior experience for the respective use-case. Therefore for contributing text, you should consider the following alternatives:

  • for tutorial and sample code use Doxygen, which offers automatic code referencing
  • for external projects use github, which offers code versioning and issue tracking
  • the rest, which is general information, should probably be on the main page for better discoverability

 

IRC channel replaced by Gitter

In case you want to chat about Ogre related topics, you can now use our Gitter channel which replaces the #ogre3d IRC channel. The reason we drop IRC is that nobody of the current Ogre Team has admin access to the channel, preventing us to set-up an archival of the chat-logs or even change the headline. Of course we could have mailed back and forth with freenode, and then request botbot.me logging  – but then Gitter took just a few clicks to set-up and offers superior code referencing..

Ogre 1.10 Mid-Term Report

With the 1.10.8 release, the 1.10 support cycle is approximately half way over, which is a good time to recap the features and switches that got introduced since the initial release.

 

Note that Ogre 1.10 is the only actively maintained release – all other branches have reached their end of life, so no bugfixes will be back-ported.
If you are still using Ogre 1.9 or even a previous release, you are encouraged to upgrade to 1.10.

 

But besides bugfixes, there were also some notable changes, which will be presented below.

Java component

Following the Python Component that got introduced with the initial 1.10 release, we now introduce the Java Component. Both of them share the same SWIG definitions, meaning they have the same API coverage.
This allows you to write pure Java applications that leverage Ogre – which is especially useful for Android development. Take a look on the updated AndroidJNI sample.

OpenGL improvements

The existing Vertex Array Object (VAO) implementation in GL3+ and GLES2 was so broken that VAOs had to be updated each frame – essentially disabling them. From 1.10.7 on VAOs work as expected and give a performance boost of about 10%.
Thanks to a contribution by Jean-Baptiste Griffo the GL3+ RenderSystem got a StateCache (accompanying GLES2 and GL). We took it as a starting point to further improve and unify the State Cache implementations and indeed could eliminate various bugs inside the GLES2 and GL caches.

Deprecation of node-less positioning

Traditionally Ogre allowed you to place Cameras and Lights in the scene without attaching them to a SceneNode. This resulted in three different positioning APIs for Cameras, Lights and SceneNodes with slight inconsistencies (Camera::move vs. SceneNode::translate) and one big one:
  • SceneNodes & Cameras look into (0,0,-1) by default
  • whereas Lights look into (0,0,1)
To make things consistent, using the Camera and Light API for positioning is deprecated now. If you want to move away from the origin, you have to attach to a SceneNode (same as you would have to with Ogre 2.x).
The only exception is Light::setDirection, which you should call with (0,0,-1) to make Lights behave like the other Nodes.
We cannot go ahead and change the default direction for 1.10 as it would break existing applications.

Compile time switches

Lets turn to some more fundamental changes that change the API and thus are hidden behind CMake switches.

OGRE_THREAD_SUPPORT == 3

To quote Steve, who initially implemented threading in Ogre:
OGRE_THREAD_SUPPORT==1 where resource management is fully threaded, was hopelessly naive. It required too many locks, and also that the rendersystem was multi-threaded. OGRE_THREAD_SUPPORT==2 improved that by not requiring that the rendersystem was threaded, and just doing disk I/O in the background, but still, the whole process is still driven within the Resource class, which means the locks are still in place on Resource and by association SharedPtr and a bunch of other classes too.
Therefore we introduce the new OGRE_THREAD_SUPPORT==3 option. Setting this, Ogre core objects – most notably Resource – are not thread-safe. However the DefaultWorkQueue is threaded. This allows the Terrain and MeshLOD Components to be multi-threaded without the locking overhead in OgreMain. See #454 for details.

OGRE_USE_STD11

Setting this option, the custom SharedPtr and AtomicScalar types become merely aliases for std::shared_ptr and std::atomic which are both more portable and higher performance alternatives.
Also std::thread is used as the default threading provider.

OGRE_NODE_STORAGE_LEGACY

Traditionally Ogre uses (hash-)maps to store everything by name, including sub-nodes and attached MovableObjects. While this gives you O(log(N)) lookup, iteration performance is terrible as maps are spread all over the memory and thus trash the CPU caches.
However with rendering the most common operation is iterating (for e.g culling) over all children while lookup is only done for changing the state. Furthermore high-frequency lookups can be easily avoided by just storing the returned pointer.
Setting OGRE_NODE_STORAGE_LEGACY=0 will use the cache friendly std::vector instead of maps. Naturally lookup by name becomes O(N) instead of O(log(N)) and the API changes. However this improves rendering performance by about 20% – bringing Ogre 1.x into 2.0 range when only a few nodes need updates. See #440 for details.

An outlook on Ogre 1.11

As the amount of possible configurations explodes with each switch we introduce, we are going to only allow one setting with Ogre 1.11 to keep things maintainable.
So rather think about the switches in terms of feature previews and not so much as options.

 

With Ogre 1.11 we will choose the following configuration:
  • Only OGRE_USE_STD11=ON will be supported. In other words Ogre will switch to C++11.
  • Only OGRE_NODE_STORAGE_LEGACY=OFF will be supported.
  • OGRE_THREAD_SUPPORT=3 will be the default. Only the std::thread provider will be supported.
  • OGRE_RESOURCEMANAGER_STRICT=ON will be the default.
  • Default Lights direction will be (0,0,-1).
  • Lots of the deprecated API will be dropped – better start looking at the deprecation warnings now.
  • Custom memory allocators will no longer be supported. You will be able to define C++11 template aliases to set them for STL containers though.

 

x3ogre presented on the Web3D 2017

At this year’s Web3D conference in Brisbane a new Ogre based X3D viewer, called x3ogre, was presented.

X3D is an ISO specified file format for 3D file transmission and interchange which is now natively available to Ogre.
The Web3D is a scientific conference concerning technologies like WebGL, X3D and glTF.

The presented viewer is called x3ogre and provides a layer for loading and manipulating X3D files inside Ogre.
Vice versa the Ogre Material and Mesh formats also become accessible inside X3D files.

To put the viewer on the Web the x3ogre leverages Emscripten and the GLES2 RenderSystem to get translated to WebGL2 and WebAssembly.

The MIT licensed implementation is available on github.

Even if you have no interest in using X3D, this is a good reference how to put Ogre on the Web and do JavaScript interoperability.