Transitioning Annwvyn form Ogre 1.9 to 2.1, probably forking BtOgre, and "fixing" Annwvyn build mess

Oh, gosh, that’s a bit painful…

So, I had this in mind for at least 3 months. Annwvyn uses a version of Ogre that is from 2013, and was built around a simple sample of using the Oculus DK1 with Ogre, using the (quite old) RenderSystem_GL, and rendering via a fixed-function pipeline…

Basically, trying to do new things with 10 year old technology (well, not quite, but that’s the idea).

I was looking at the news pages of the website of Ogre3D, that I never go see, because well. I was interested in the SDK download page. Problem is : what is on that web-page, is a SDK built in 2013. Ogre’s development is in quite a weird state right now. The source code has multiple branches right now :

  • Ogre 1.9, a “stable” version related in 2013 apparently
  • Ogre 1.10, with active development, that has improvement, bug fixes and some backport from the new 2.x branch. And it still run on older hardware.
  • Ogre 2.0, A new version of Ogre that introduce a lot of performance improvement, a new compositor system. It currently works on all desktop and mobile platform
  • Ogre 2.1 Adds a new system that replace the “Real Time Shader System” Ogre had. It’s called HLMS for High Level Material System. It’s made from the get go to use modern rendering techniques, and not for “emulating” the old fixed function pipeline with shader code. But only works on windows and Linux, and iOS/Mac via the Metal API at the time I’m writing this blog.

So, since I looked at PBR rendering, and all the shiny new things, I want Annwvyn to do that. I never really gave much thought on the graphic part of things because I was working on getting the other systems of the game engine to work.

So, I’m currently working on a Ogre21 branch. The rendering is working, and most of the engine is now ready to run with it. But there’s a lot of breaking changes, both in the API and in the way the content the engine uses is prepared to take advantage of the new HLMS system.

For now, there’s no “good way” to export Ogre 2.1 mesh and materials from a program like blender. Older mesh format works, and right now Annwvyn expect “old mesh format” and convert it internally to Ogre 2.1 mesh data, but still keep the v1 mesh to generate physical rigid bodies. This is done by a library called BtOgre that is not really ported to 2.1. Some work has been done on GitHub by a user called nyxkn, and I rewrote a debug drawer that can display bullet’s geometry in 3D view.

I think I’m probably going to fix this, and by doing so, I’m reorganizing the code of BtOgre. I’m not sure how to go with it. The original author of the library isn’t really working on it as far as I know, and I’m not happy with the way some of the code of BtOgre has been organized is. So I think I’m going to fork it completely and start from there

This brings me to the final point I want to talk about : Building Annwvyn is a mess. You have to have the libraries set up in a correct path and then you need to open a visual studio solution with the correct version of the compiler and… you get the idea. I need an actual build system and a way to manage theses dependencies.

From a developing stand point, I come from the Linux world where, basically, you either know that libraries will be in /usr/lib or /usr/local/lib (same goes for includes) or you “pkg-config” your way out of the problem. Well, on windows you don’t h ave standard libraries path locations, and you don’t have tools to magically spit out tags for compilers to find your stuff… So, I need the solution to be “less worse”.

Ogre is using CMake as a build system, and has a separate repository for it’s dependencies, all in the same place. I think I should start by actually learning how CMake works, and make it generate visual studio solutions, or makefiles, or anything like this that it would need to work, and rebuild the whole “Annwvyn SDK” to use it.

Source: New feed

Leave Comment

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