News

New build scripts for 2.1 and 2.2!

We’ve often been told building Ogre from source is hard.

And they’re right!

Which is why we tried our best and prepared quick start scripts that will clone all necessary dependencies, configure CMake and build for you!

Grab the download scripts:

Unzip them and run the script that matches your platform and OS!

For example if you’re on Windows and have Visual Studio, run either:

  • build_ogre_Visual_Studio_15_2017_Win32.bat
  • build_ogre_Visual_Studio_15_2017_x64.bat

depending on the architecture you want to build for (e.g. 32-bit vs 64-bit)

The scripts will automatically start building, but you will also find the Visual Studio solution files under Ogre/build/OGRE.sln

If you’re on Linux, run either:

  • ./build_ogre_linux_c++98.sh
  • ./build_ogre_linux_c++11.sh
  • ./build_ogre_linux_c++latest.sh

Which one you need depends on the C++ version you’re targetting. C++98 compiles much faster than the rest, but may have incompatibilities (particularly with std::string) if mixed in a project build for C++11 or newer

There are currently no build scripts for Apple ecosystem. For building for iOS, refer to the Setting up Guide. The instructions for Linux should work for building for macOS, but may require additional manual intervention.

We hope this makes your life easier! And let us know if you encounter problems with these scripts! The goal is that building Ogre from scratch becomes as simple as tapping a few clicks.

Further discussion on forum post.

Progress Report July 2019

Hoo boy! This report was scheduled for January but couldn’t be released on time for various reasons.

We have another report coming as this is old news already! We have another report coming mostly talking about VTC (Voxel Cone Tracing) which is a very interesting feature that has been in development during this year.

But until then, let’s talk about all the other features that have been implemented so far!

read more…

2.2 branch no longer WIP

If you’re tracking our repo you may have observed we renamed the v2-2-WIP branch into v2-2

What does this mean?

It means the branch is stabilizing. Back when it was v2-2-WIP, it was very unstable. Checking out that branch meant you could find crashes, memory leaks, missing or broken features; and the API interface was changing very quickly, thus updating the repository could mean your code would no longer compile and required adapting.

Over the last couple months, the API interfaces on 2.2 had begun to settle down, bugs were fixed and there were no apparent leaks. In fact some teams started already using it.

Now that it is no longer WIP, while there could still be API breakage on the 2.2 branch or accidental crashes/regressions, it shouldn’t be anything serious or that requires intensive porting.

We still have a few missing features (such as saving textures as DDS) but they’re not used frequently.

Coming up next

We still owe you a Progress Report of what’s been going on in 2.1 and 2.2 in the past year and a half; we have that written down but still needs a few reviews.

Coming up next is:

  • More real time GI improvements
  • VR performance optimizations
  • We are planning on a Vulkan/D3D12 backend

Additionally we have a community member working on GPU-driven rendering and GPU particle FXs; while another community member just contributed Morph animations to 2.1

Yes, Morph animations are finally HW accelerated again! We are evaluating on porting this contribution to 2.2; it shouldn’t take long but we’re evaluating if it can be improved with the use of Compute Shaders

What about Ogre 2.1?

If someone wants to teach Matias aka dark_sylinc a quick automated way to create installer SDKs, that is welcomed! (he never liked handling that!!!)

Ogre 2.1 has been very stable. Eugene ported several improvements from the 1.x branch; and we currently are dealing with a regression that caused due to how PF_BYTE_LA / PF_L8 format is treated in D3D11, but other than that 2.1 is ready for release.

The morph animation contribution is brand new so that may need a bit more testing.

If you don’t see an SDK that is mostly due to time and knowledge to package an SDK.

If someone else wants to step in and maintain packaging, that is welcomed!

Further discussion in the Forum Post

Ogre 1.12 released

We just tagged the Ogre 1.12 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.11 release. Compared to the last Ogre 1.11 release (1.11.5), 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 is still missing. We will update the download page as it becomes available.

read more…

Ogre 1.11 User Survey Results

During the period of Feb 27. – March 27. we received 60 replies. At the same time the ogre 1.11.5 Windows SDK alone was downloaded 644 times. So while the results are significant, they are probably not representative.

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

Specific replies

Following the #MeanTweets idea I also wrote some short replies to the criticism, that you can read below:

read more…

Ogre 1.11 User Survey 2019

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.

As we have started the 1.12 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 27th 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 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.