Ogre Rendering?

Following the release of 0.1, I've spent my time doing a few fun things besides straightforward coding. One of them is that I've been looking into moving to rendering using Ogre. The main downside to this is that Ogre wouldn't be as optimized for the Sauerbraten geometry and so forth, so there would be a significant performance hit. It would also in all likelihood lead to larger executables and RAM usages.

Still, the benefits are interesting enough for me to spend a few days playing around with the code:

• The main benefit is that Ogre is developer-friendly and extensible; adding new effects and so forth in that framework is much easier than in the Sauerbraten one.
• A further benefit is that Ogre abstracts the underlying rendering API (OpenGL, DirectX, etc.), and includes plugins for both OpenGL and DirectX; this is of interest to me mainly because DirectX drivers are at times of higher quality on Windows. (More effort put into them by Microsoft, perhaps?) It also opens up far more feasible opportunities to port to other rendering methods (OpenGL ES for mobile devices, and so forth) - this would be quite cumbersome with Sauerbraten itself, as OpenGL code is interleaved with application code all around.
  
• A final benefit, but of lower importance, is that feature-wise Ogre has several attractive capabilities, like various shadowing algorithms, multiple poses for meshes, and also that Ogre has a larger developer community around it.
  

In the end, it'll come down to how complicated it is to do, and how much of a performance hit it incurs. So, I set out to estimate both things. So far I have a very initial demonstration of rendering cube geometry using Ogre instead of the Sauerbraten rendering system - basically, I take the output (vertexes, triangles, etc.) of the Sauerbraten pipeline and convert it into an Ogre-appropriate form. Here is a screenshot:


It's not much to look at, in fact it is downright offensive to the eyes :) But it shows this can be done.

This was not too complicated, but not easy either. However, I am of the opinion that further integration with Ogre - lighting, models, particle effects, etc. - will be somewhat easier with this framework in place, and given that I will be using almost 100% Ogre for them (whereas here I still utilize almost all of the world geometry processing code from Sauer).

Performance-wise, this wasn't much of a test - just a simple map with a few thousand polygons. Still, it didn't reveal any immediate performance problems, so it's good enough to continue forward with.

My thinking at this point is that I'll continue to hack on the branch dedicated to Ogre, while continuing forward with the main branch alongside that. The only thing I might do differently is take care not to do any work in the main branch that might conflict with merging the Ogre branch later on (so, e.g., I won't work on a nice interface for Sauerbraten particle effects, since I might end up using the Ogre system for that anyhow).

My current goal is for a 0.2 release in about a month, which would include bugfixes and several minor but important features. I'll probably make a decision regarding Ogre around that time, and assuming I do decide to go with Ogre, then the 0.3 release might be dedicated to that purpose.