How mature is MOGRE?

Here's the deal: I've always been a huge OGRE fan, but my current game project is not being written in C++. I think C++ is great, but I enjoy the ease of development offered in the managed world. Considering my game won't be doing 8 textures per mesh, bump mapping, normal mapping, etc., I can afford the very minor performance hit going managed will give me (especially small since I will ngen the images on install of the game package).

That said, Ogre.Net has always been a little behind the current Ogre release, and last time I played with it, it had some issues. Great project idea, but it was flaky at times. Axiom is not kept close enough to the current Ogre for me to use that. I've been going down the path of writing my own specialized render engine using MDX and the Tao framework, but you can imagine how much time this takes.

So what I want to know is...how mature is MOGRE? Can it be used in a serious project with the expectation that 95+% of OGRE should work well? Or should I expect some headaches? I would really like to use Ogre as my rendering back end, but my decision to go managed is firm and won't change. If MOGRE can offer me a reasonably mature managed path in to Ogre, I will go that route.

Ogre.Net has always been a little behind the current Ogre release, and last time I played with it, it had some issues. Great project idea, but it was flaky at times. Axiom is not kept close enough to the current Ogre for me to use that.
That's the reasons that I started Mogre, Axiom too far behind and OgreDotNet too many issues/limitations.
I consider Mogre fairly stable (ok, the occasional bug may appear now and then) and it covers almost the full Ogre API.

For limitations and stuff that needs to be done you can read the roadmap. Also bear in mind that the CeguiNet libraries are those from OgreDotNet, so they have the same headaches/issues of SWIG.

One more question: Where did you get the C++/CLI AutoWrapper? Or did you write it? I would love to use something like that to generate a managed wrapper for OIS.

OIS is pretty small. I feel a wrapper is uneeded. What I would like to see, would be a straight port to CLI/C++ of OIS. If the code to make a managed layer is small, it could be in the standard OIS codebase gaurded by an ifdef. Though, I havn't looked into what is needed.

Of course, a CLI port (like Mogre) would limit Managed OIS to .Net on Windows (for now).

OIS is pretty small. I feel a wrapper is uneeded. What I would like to see, would be a straight port to CLI/C++ of OIS. If the code to make a managed layer is small, it could be in the standard OIS codebase gaurded by an ifdef. Though, I havn't looked into what is needed.

Of course, a CLI port (like Mogre) would limit Managed OIS to .Net on Windows (for now).

Straight porting it is not quite as easy as it sounds. and your code would be littered with #ifdef's when you were done. For instance, everything that returns char * now, must return String^ in a CLI port. Pointers have to become IntPtr, etc. Basically every method would have an #ifdef/#else/#endif block because even things like getters and setters work quite a bit different in C++ and C++/CLI. You can get around some of it with some fancy macro work (like defining OIS_String as std::string/char * (not sure which you use), and String^ for the Managed world.

It's possible, but could get very messy, very fast, which is why a wrapper is usually easier for the maintainer of the original package...but OIS is your baby, not mine