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.
OGRE scripts offer a way to define materials at an abstraction level similar to D3D Effects and CgFX where you can define alternative techniques, each consisting of one or multiple passes. Here, each pass defines a render pipeline state by defining blend modes and referencing shaders. The main difference in OGRE is that you cannot write inline shaders in the script file as we support different render systems with different shading languages.
Traditionally, OGRE allows to use fixed function pipeline (FFP) functionality where you do not have to write any shaders, as long as Phong shading and a fixed set of texture operations is enough for your use case.
However, modern Render Systems like D3D11 or GL3 no longer include FFP parts to reflect that modern hardware does not either and is rather based on unified programmable SIMT pipelines.
To abstract form this difference, OGRE therefore offers the Real Time Shader System (RTSS) component, that generates shaders that seamlessly replace the absent FFP functionality. In most cases OGRE is able to produce pixel-perfect results.
However, as the RTSS generates shaders internally, you can customize the rendering in much more detail then was possible with the FFP. Here, you do not have to write your own shaders but can keep the high abstraction that OGRE scripts offer and just use the rtshader_system section to declare the features you want. Still this, gives you a large amount of control how things are rendered.
The most simple thing to do is enabling per pixel lighting (which is default in 1.12 anyway) or make the shading respect the physical energy conservation rule as described here.
However, the RTSS also enables you to create complex custom render pipelines via OGRE scripts as it offers the following features (the emphasized parts require OGRE 1.12.5)
Hardware skinning
Instancing
GBuffers
Depth texture shadows
Lighting models
Triplanar Texturing
Offset mapping
Below are some examples how this might look like:
Hardware Instancing with Integrated shadows
Integrated single pass offset mapping
The first screenshot shows the instancing sample, where the RTSS extended the vertex shader to read from the instance buffer as well as the fragment shader to apply depth based shadows. If you switch to the PF_DEPTH format for the depth texture, it will automatically use hardware PCF as it does not incur any performance penalty.
The second screenshot shows integrated offset mapping with multiple lights. As this is handled by the RTSS as well, it can be combined with hardware skinning and instancing – all you need is to add a single line in your material. No need to touch any shader code, while being compatible to all supported render systems.
See the respective Samples on how to integrate this in your own projects.
Deprecation of the HLMS backport
If you are familiar with OGRE, you probably also know that there is the High Level Material System Component in OGRE1. Actually this Component is a backport of the respective core element of OGRE-next (2.1+), where it handles shader variations and thus has a similar goal of the RTSS.
However, it got only little love in OGRE1 after the initial backport, so even as of today there is no way to use it form OGRE scripts. Also I am not aware of any users, as there was not a single bug-report regarding the HLMS. To reflect that the RTSS is in all cases the preferred alternative, the HLMS is therefore deprecated in OGRE1 and will be removed with the next release, if nobody steps up to object.
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:
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.
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.
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.
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.
Hardware skinning and multiple shadows via the RTSS
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.
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.
