So, I’ve been asked about my thoughts on the Ogre 2.1 release, and the implications for OpenMW. Here they are.
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.
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.
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:
– 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.
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.