Modern OpenGL with OGRE1

Everybody is starting into a new year with good resolutions, so you can now take an advantage of modern OpenGL3+ concepts with OGRE .

Shader storage blocks

The first one is “Uniform Buffer Objects” (UBO) and “Shader Storage Buffer Objects” (SSBO) or simply “shared GPU Parameters” in OGRE speak.
The shared GPU parameters have gained a backing HardwareBuffer which is used for communicating with the GPU.
With OpenGL this can be either a UBO or SSBO which is detected from your shader code and automatically bound if possible.
In case of a SSBO it is possible to read-back the data from the GPU, which is triggered by the new GpuSharedParameters::download() method.
This gives you an easy way to retrieve results from the GPU without rendering to a Texture or Vertex Buffer.

Separate Shader Objects and SPIRV

Traditionally OGRE internally uses monolithic programs for GLSL that explicitly glue vertex and fragment shaders together. Notably, this means the GpuProgramParameters are only valid per combination and not per individual shader.

However, from the API perspective Ogre always exposed the DirectX model without explicit grouping – e.g. in material scripts. This approach is commonly referred to as “mix and match”.

Ogre tries hard to hide this difference for you. For instance one can only retrieve the active uniforms from GLSL once it is linked. This happens on the first render call in OpenGL – instead of at material parsing time when OGRE would need it.
Therefore OGRE goes ahead and parses the GLSL source code itself to figure out the available uniforms. Needless to say, this is quite error prone and does not support more advanced constructs e.g. struct uniforms.

Fortunately, OpenGL provides the DirectX like behaviour via “Separate Shader Objects” (SSO) that allow linking individual shaders and bundling them to pipelines later.
Now we finally take advantage of them and at this also uses ARB_program_interface_query for parsing the uniforms in a standard way and cover all corner cases.
Notably, this allows us to reference uniforms by location only – like in the good old assembly days:

vertex_program Ogre/Compositor/StdQuad_Tex2a_vp spirv
{
    source StdQuad_Tex2a_vp.vert.spv
    default_params
    {
        param_indexed_auto 0 worldviewproj_matrix
    }
}

The corresponding GLSL code for that uniform would be

layout(location = 0) uniform mat4 worldViewProj;

You might wonder why you should care; if you look closely the material snippet above is using SPIRV binary shaders, where the uniform names are stripped away and only the locations are available.

Therefore this is necessary for support of pre-compiled SPIRV shaders, which is now complete.

And while we are at it – why are SPIRV shaders cool? Well, you can compile HLSL to SPIRV and then use it with OpenGL 😉
Also, this is a pre-requisite for the Vulkan back-end and this way you can prepare you shader authoring accordingly.

If you would like to learn more about using SPIRV in OGRE, see here.

Currently (in master) you have to manually enable SSO support via the “Separate Shader Objects” RenderSystem option.
Using OpenGL for shader parsing has some side effects; notably you will now get errors when trying to set an unused (and thus optimized away) uniform. Typically this means your shader is broken – but we traditionally keep your code working during a release support period.

Ogre 1.12.4 released

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.

Other notable changes

  • Continued effort of porting Samples away from Cg
  • Documented the Matrix conversion behavior between OGRE (row-major) and GLSL (column-major)
  • 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.

Ogre 1.12.3 released

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.

New Features

  • Reversed-depth buffer support for D3D11 and OpenGL3+. See the accompanying tutorial for details.
  • Full Unicode Path support, including ZIP archives, on Windows (on by default)
  • The Real Time Shader System, now uses ShaderModel4 style texture sampling, which fixes multiple samples (mainly depth and 1D texture related)
  • Overlays now properly support content scaling, which is needed for HiDPI screens.
  • Native ImGui support through the Overlay component
The new ImGui Sample

Ogre Ecosystem Roundup #3

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

Ogre-next project split

So lets put first things first; Ogre v1 and Ogre v2 are not only different versions of Ogre, but rather separate projects. Now officially.

While this sounds like big news, actually it is not that much of a change. If you followed the development of Ogre, you already noticed that the two branches moved independently in two separate directions. Hence, we had to write the what version to choose page.

Generally, Ogre2 focuses on the latest and fastest techniques, Ogre1 focuses on backward compatibility and keeping old projects running. Also Ogre1 is developed on github, while Ogre2 still lives on bitbucket.

With bitbucket now abandoning mercurial, we decided to move Ogre2 to github as well. While we could have kept it in a branch, we instead decided to create a separate repository with own issue tracking, landing page etc. So, enter ogre-next.

This also makes it possible to follow semver with Ogre1 and make a 2.0 release when needed.

(more…)