Thoughts on Ogre 2.1 release

So, I’ve been asked about my thoughts on the Ogre 2.1 release, and the implications for OpenMW. Here they are.

OpenGL3 requirement

The 2.1 branch has dropped all support for OpenGL2. OpenMW was never meant to run on hardware that originally ran Morrowind – still, dropping GL2 support seems a bit extreme at this time. For example, the open source Mesa drivers haven’t caught up to that point yet (at least not on Ubuntu 14.04, and thus one of my dev machines). Admittedly this may become more or less irrelevant a few years down the line.

Diverging branches

Development is currently split across 3 different unstable branches (1.10, 2.0 and 2.1). 2.0 and 2.1 are lagging behind the 1.10 branch with 500+ unmerged fixes. This makes contribution unattractive to say the least.

New material system

This is the feature I was looking forward to the most, but now I’m a little disappointed. The shader macro system is very basic and does not appear to support setting a uniform to a material property or to a scene parameter. Most of the work is done by the C++ implementation which is tightly coupled to a specific shader.

The default Physically Based Shading materials are nice but obviously not usable with Morrowind’s lighting system. Coding custom materials is possible but not without intimate knowledge of the underlying AZDO backend. The default PBS material C++ implementation comes at a whopping 2000+ lines and makes use of a “command buffer” and “vao manager” that we can obviously not expect Ogre users to be familiar with.

This also goes against the principle of making the shaders as user-modifiable as possible, one of my main goals with the rendering backend in OpenMW.

The general issue is trading flexibility and fast prototyping for hardcore performance. Overall, not something I am comfortable using, so I started looking for alternatives.

Meet OpenSceneGraph

OpenSceneGraph is an established high performance 3D graphics engine using OpenGL. I took a detailed look and fell in love with its design. All features we need are provided:

– Occlusion query: check.
– DDS support: check.
– Particle systems: check.
– Vertex morph animation: check.
– Skeletal animation and “tag points”: check.
– SDL integration: check (hopefully less buggy than Ogre’s).
– Native (!) QT integration: check.
– Camera relative rendering: check.
– Visibility flags check, render queue groups (“render bins”) check.
– Windows, Mac OS X, Linux, Android support: check.

On top of that, in no particular order, a list of issues we’re having with Ogre, that won’t be an issue with OSG:

Non uniform character scaling along with non-uniform scales in NIF files should work properly (OSG uses a 4×4 matrix transform).

– Material stencil support: Ogre does not support stencil settings in its material system, which can be used by NIF files. OSG does support it. Admittedly not a very prominent feature, still nice to have.

– Culled nodes should be updated properly, fixing game logic problems.

Other notable changes

No resource system

OSG does not require a resource system, all loading can be done by the user. Hell yes! Ogre’s resource system was always ugly in that it expects everything (be it a material, mesh or texture) to be named, which *is* a real problem when internal resources conflict with user-defined resources. There are also inherent problems with Ogre’s resource manager being a singleton; we need multiple resource managers in OpenCS, one for each document.

In fact, the Ogre folk realized this mistake long ago and started a “Resource system redesign” GSOC project, which unfortunately to this day has not been finished.

No DirectX

Dropping support for this particular render system has been on my list for a while. If it were not for Ogre’s terrible OpenGL performance this would have been done a long time ago. I look forward to being able to write shaders directly in GLSL rather than using the compatibility header we have in place. Another problem was that bugs cropping up with that renderer can not be fixed by me and tend to accumulate.

6 thoughts on “Thoughts on Ogre 2.1 release

  1. Kyosho

    So is OpenMW moving to OSG, then? Rather than moving to Ogre 2.0/2.1? Or are you still in the process of investigating whether it’s feasible?

    Reply
  2. Pavel

    I have the feeling you jumped at conclusions here:
    * MESA actually supports OpenGL3.3 – if your hardware does [1]
    * if you really want GL2, you could also use the GLES2 Renderer on Desktop (ES context or glew)
    * the 1.10 branch was merged into 2.0 and 2.1 just today [2]
    * you can still use the old material system with HLMS Low Level [3]
    * you are basically moving to a system without anything like HLMS/ Shiny instead of plugging in the missing bits into HLMS, which can be hardly the easier path..

    [1] http://mesamatrix.net/#Version_OpenGL3.3-GLSL3.30
    [2] https://bitbucket.org/sinbad/ogre/commits/85587b26b7afe8dd8382b9d2edb71bb1d13916ac?at=v2-1
    [3] https://bitbucket.org/sinbad/ogre/src/2213aed8e9492372adc057573ff7bae290df2371/OgreMain/include/OgreHlmsLowLevel.h?at=v2-1

    Reply
    1. scrawl Post author

      * MESA actually supports OpenGL3.3 – if your hardware does [1]

      On sufficiently new versions of MESA, that is. The version packaged in Ubuntu 14.04 does not support it, as far as I can tell.

      * if you really want GL2, you could also use the GLES2 Renderer on Desktop (ES context or glew)

      I have tried the GLES2 renderer, but it’s crashing with mesa, see post http://www.ogre3d.org/forums/viewtopic.php?f=4&t=81732&p=514684#p514684.

      * the 1.10 branch was merged into 2.0 and 2.1 just today [2]

      Ah, cool.

      * you can still use the old material system with HLMS Low Level [3]

      Yes you can, but as the code comment states this way is slow and not recommended for general usage.

      * you are basically moving to a system without anything like HLMS/ Shiny instead of plugging in the missing bits into HLMS…

      Definitely not a matter of plugging in missing bits, it would take a rewrite from scratch. I need the system to be easy to extend, not just easy to use, for our users’ sake. The way the AZDO optimizations are implemented makes this impossible.

      Reply
  3. Pavel

    On sufficiently new versions of MESA, that is. The version packaged in Ubuntu 14.04 does not support it, as far as I can tell.
    Mesa 10.1.3 should already be able to do 3.3 [1]. You could try upgrading to 14.04.2 (install mesa-common-dev-lts-utopic etc. [2]) but I am afraid your hardware simply does not support 3.3.

    I have tried the GLES2 renderer, but it’s crashing with mesa, see post
    a wild guess would be that glGetString(GL_EXTENSIONS) is at fault as this call is invalid in core profile. maybe MESA messed up there something.

    Regarding the HLMS slow path: my guess would be that it is the same speed as 1.10 (or 2.0).

    The concept behind the HLMS fast path are UBOs[3]. This precisely boils down to not changing single uniforms, but batching the changes to blocks and caching them between draw calls/ shaders. If you do not do this you lose performance – if you do, you will need some C++ code which groups your properties: HLMS. (additionally it has a shiny like preprocessor)

    [1] http://en.wikipedia.org/wiki/Mesa_(computer_graphics)
    [2] https://wiki.ubuntu.com/Kernel/LTSEnablementStack#Desktop
    [3] https://www.packtpub.com/books/content/opengl-40-using-uniform-blocks-and-uniform-buffer-objects

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *