Ogre 1.11 Mid-Term Report

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

Good time to Contribute

If you are porting your Code to Ogre 1.11 now and find that you have local changes, it is a good time to create a pull-request and contribute them upstream.

This way you make sure that your fixes will be carried forward by the Ogre team as well as getting expert feedback on your change. This will eventually boost your productivity as well as helping Ogre.

OGRECave ecosystem

  • Scape got substantially improved by Tobias Schmidt. Now all tools and import/ export work.
  • ogre-assimp got fixes for Texture exporting with 1.11 and proper normal handling.
  • ogre-video got updated for 1.11 and is now the recommended video plugin.

Overview

But lets turn to the new features now. Specifically:

  • Sampler Objects
  • Improved Compositors
  • Templated Vector
  • Unified Documentation

Sampler Objects

We started adapting the internal RenderSystem API to how modern graphics APIs like Vulkan or Gallium3D work by introducing ColourBlendState and Sampler Objects.

Sampler Objects are Script-User visible and therefore we will describe them in more detail. Essentially they store all parameters controlling how Texture data is fetched. Previously those were scattered around TextureUnitState (TUS).

Now you have separate, named Objects that are created by the TextureManager. This allows you to quickly change the settings for all associated Textures. Typically you have many Textures but only a few sampling states in your application.

We also use this mechanism inside Ogre to providing a DefaultSampler object which is shared by all TextureUnitStates. Calling MaterialManager::setDefaultTextureFiltering now simply modifies this DefaultSampler. If you modify one of the sampler parameters via the existing TUS API, we transparently create a new Sampler for this Unit – which results in a much cleaner implementation compared to the various  flags used before.

sampler NoInterpolation
{
    tex_address_mode clamp
    filtering none
}

material Example
{
    technique
    {
        pass
        {
            ...
            texture_unit
            {
                texture foo.png
                sampler_ref NoInterpolation
            }
            texture_unit
            {
                texture bar.png
                sampler_ref NoInterpolation
            }
        }
    }
}

Currently Samplers only directly map to GL3.3 API Objects, but the same can be done for D3D11 and GLES3.

Improved Compositors

The Compositor System now supports PF_DEPTH16 for RenderTextures and fully integrates with the RTSS, enabling the auto generation of shaders.

Together these features allow you to render and display depth of your scene as easy as

material ShowDepth {
    technique {
        pass {
            lighting off
            texture_unit {
                filtering none
            }
        }
    }
}

compositor Texcoord
{
    technique
    {
        texture depthTex target_width target_height PF_DEPTH16
        target depthTex
        {
            pass clear {}
            pass render_scene {}
        }
        target_output
        {
            pass render_quad
            {
                material ShowDepth
                input 0 depth
            }
        }
    }
}

Note that this script will work across all RenderSystems as the (GLSL/ HLSL) shaders will be auto-generated.

Additionally there is now a new “compute” compositor pass for explicitly dispatching compute shaders

compositor Compute
{
    technique
    {
        target_output
        {
            // just do normal rendering
            input previous
            // execute compute shaders post-render
            pass compute
            {
                material Compute/Compositor
                thread_groups 16 16 1
            }
        }
    }
}

where the Compute/Compositor material has one or more compute only passes, which can access any of the global auto-constants. Note that binding textures for UAV read/ write is not yet possible through scripts yet.

Templated Vector

Vector2, Vector3 and Vector4 are now just typdefs of the Vector<N, type> template. (e.g. Vector3 is Vector<3, Real>)

This allows you to use custom Vector types and is the first step to combat the Real type abuse in the code-base; initially the Real typedef was introduced as a configuration option for SceneNode calculations with double precision.

However at some point Real started to be used instead of float everywhere, but for most part the type must be float and not double. E.g. meshes are always stored at float precision as most RenderSystems did not support it double precision. Therefore all code interacting with meshes should work on floats exclusively (sparing some dot operations with large numbers).

Unified documentation

While we already merged the Ogre manual and the API reference with the 1.10 release, the Docs are now becoming truly unified regarding the content;

An outlook on Ogre 1.12

New features will still land in 1.11.x point releases, so the 1.12.0 will be just the last 1.11 without some deprecated features (just as 1.11.0 was compared to 1.10.12).

Therefore this is mainly to inform you about the API breakage coming with 1.12, which currently is

  • bump required OpenGL version for GL3+ to 3.3
  • remove some of the dragging deprecated API. (including script parameters)
  • switch Overlays to the unified parser.
  • drop compute shader execution during rendering

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.