Let's talk about Ogre/Mogre 1.8

I was thinking a little bit about the further develoment of Mogre. As I read on the Ogre news page:
We as the Ogre team have also started preparing a new release, namely a first RC for Ogre 1.8 and we plan to publish the final stable version right on the turn of the year.
I am afraid that Mogre is not yet ready for the next release since we are currently without maintainer. Since I do not have deep knowlegde of the development of Ogre I do not know if there are big changes that we need to consider in a new Mogre release. Anybody who has some deeper insight is welcome to share his or her knowledge!

What I already read in the forums:
Apart from using mercurial to grab it, everything is the same. It's still using cmake (which I rip out using ruby scripts, cmake pisses me off).

The only downside I can think of is that mogre hasn't caught up yet (well, I haven't looked since about 12 weeks ago), so if you used mogre for a level editor or something it wouldn't be able to have the same features and it couldn't open 1.8 meshes.
Thank you in advance for any expert (and non-expert ) responses!

Mogre (Ogre) version would be good if built development for the night.

Sorry, I do not understand what you mean, can you please explain again?

( Mogre 1.8 ) - I think, binary version should be published daily or monthly.

Daily is impossible, I think. There is nobody in the community who can spend so much time a day for Mogre if it is used only by such a small group of people. Besides of that: There are not changes every day because the Mogre developers only need to care about changes in the Ogre API, most fixes and changes the Ogre team is doing are not important for the Mogre development (since Mogre is a wrapper). So most days only the binbary from the day before would be "released".

So maybe monthly: I do not know, this depends on the development of Ogre as said above. But some kind of regular updates would be good to keep the Mogre community together and Mogre itself alive. Anyway I think four times a year would be more useful than every month. Maybe there is also a fixed table for Ogre releases we could use to find a rhythm...

But besides of the number of releases I created this topic to discuss the further development of Mogre. The problem is that mstoyke might finish the wrapper for OgreTerrain and OgrePaging but he will probably not come back as a maintainer. Unfortunately there seems to be nobody with enough knowledge to replace him. So I would like to know from the community how the development of Mogre should be going on.

I think this is an important question. I'm betting there are many lurkers on these forums who use Mogre that never post (like me). I am fairly vested in C# with Mogre - and the thought of having to adopt another (less elegant) .NET scene managerment solution or return to C++ are both less than appealing. There are many features in 1.8.x, such as DX11 support (hardware instancing, etc), the new terrain system, etc. that I'm sure many of us are looking forward to in 1.8.

I'm betting there are many lurkers on these forums who use Mogre that never post (like me).
I hope you are right. It would be a shame if Mogre gets outdated even if there are a lot of users, so we need a strong(er) community. And of course because of the facts you mentioned (other wrapper or back to C++ ) But: You made a good start with your posting

There are many features in 1.8.x, such as DX11 support (hardware instancing, etc), the new terrain system, etc.
It would be great to have a full list of changes from Ogre 1.7(.3) to Ogre 1.8. This is needed to know where Mogre needs to be updated.
DirectX 11 support for example is covered with the Direct3D11 rendersystem which is kind of a plugin and doesn't need to be wrapped, the new terrain system is a component that needs to be wrapped (we have the pre-alpha wrapper of it from mstoyke).
Unfortunately I do not know how a new Mogre release is prepared. I checked the Mogre repository and looked at the changes mstoyke made to wrap the new components: take a look here. There are actually no changes in the code (just some small ones) but mostly in configuration files. So far I did not find out how these files work, so if anyone can clear this up...

I'd be willing to help out, but I'm completely useless when it comes to dealing with C++/CLI so I'm not sure how useful I'll be on the building/compiling side of things

I'd be willing to help out, but I'm completely useless when it comes to dealing with C++/CLI so I'm not sure how useful I'll be on the building/compiling side of things
Willing is the first important thing as far as I can see there is not so much stuff that needs to deal with C++/CLI. A big part of the wrapping progress is about writing config files for doxygen and extending the AutoWrap tool which is written in C#.

Building/compiling/testing should be possible for everyone, I hope. It' just about hitting F5

In best case we just need to apply the Ogre API changes, run the autowrapper (with the needed background information) and have a fresh Mogre 1.8.

In worst case we have much trouble.
One reason could be that Ogre switched it's build process from ?? to cmake.
The Mogre autowrapper needs some modifications/additions to the Ogre code to do the wrapping job. I suppose the old build system had an option for creating that modifications/additions. Unfortunately I don't know details. I just know about such problems from an old discussion with the retired Mogre maintainer mstoyke.

( Mogre 1.8 ) - I think, binary version should be published daily or monthly.
Frequently builds are only useful when sources are updated very often.
I suppose there were no changes of the Mogre for months now.
Additionally we can't build Mogre automatically. So it would need much work by hand. As I read this should be a complicated process and not many users could do it. (I seems so that for most users it's enough to take precompiled binaries.)
We are happy that user Cygon did build everything from the base as one bundle. It's a good base.

So maybe monthly [...] four times a year would be more useful
I think it makes no sense to talk about a time span.
We have less human ressources and as I said - official (well tested) Ogre upgrades are not very often. More than one build for one Ogre release doesn't make much sense (in my point of view).

Additionally:

1. To create a build needs time[/*:m]
   
2. Each build should be tested (at least a quick test)[/*:m]
   
3. Download links, etc should be updated[/*:m]
   
4. The Mogre SDK should be updated (because I suppose many newcomers just use this instead of plain binaries.)[/*:m]
   
5. I _suppose_ there are not very much users, who would use the binaries.
   So - how big is the benifit if one of us spend much free time for high frequently builds?[/*:m]
   
6. Do we need updates immediately? In general Mogre works well and offers many features.
   (For example my application still uses Mogre 1.6 and it's still well)[/*:m][/list:u]
   
   I'm not against more updates. I just want to say it's difficult for our small (active) community.
   Look to the Mogre SDK. For about 2 years nobody had time to update it.
   Also people want to focus to their own interests/projects instead of working on other points, which they don't need.
   
   In the past it was like this:
   Mogre users were focused on their own projects.
   They shared several improvements (updates, add-ons, ported C++ code, etc.) and gave support in the forums. My focus was mainly to put useful information to the wiki for documentation purpose.
   Some users also did community work (e.g. updates), which had no personal benifit. But this is not the main focus of hobby users.
   
   So we just have to hope that there are always active people, who share her personal improvements with the community.
   We don't have the power to offer a "full support" for Mogre.
   When one of us updates Mogre to a newer version it's fine.
   But we can't force anybody to do the job.
   If I could force people, I wouldn't do it, because we need motivated people with passion. No slaves with decreasing motivation.
   
   There are many features in 1.8.x, such as DX11 support (hardware instancing, etc), the new terrain system, etc. that I'm sure many of us are looking forward to in 1.8.
   Well, I agree that it would be very good to have a Mogre 1.8 version.
   The questions are: Who has time, motivation and specialist knowledge to do the job.
   I hope there will be somebody. Also I suppose there is a good chance, because it would be a benifit for the person who do the job, too.
   
   I'm not shure if Ogre 1.8 offers full DX11 support. Some (many?) months ago I read, that the maintainers have problems with the implementation speed. (I'm not shure to which version it belongs, but full DX11 support was moved on the road map. Either from Ogre 1.7 to 1.8 OR from 1.8 to the next release.)
   Main points for 1.8 are listed here:
   http://www.ogre3d.org/tikiwiki/ByatisNotes
   (Note: It's a mixture of changelog and a roadmap / todo list. Full details will be published on the Ogre homepage news tracker with the official release of Ogre 1.8.)
   
   
   So, these are my spontaneous thoughts.

Hitting F5 is not enough to autowrap and build Mogre.
Nevertheless there are some notes about building Mogre in the wiki. (here)

And we have a Mogre build tool. It's mostly ready, but still has some problems. Perhaps it would be useful, if someone else look to the current development state. Maybe he can solve the open gaps.
Details: Mogre.Builder - a tool for easy, automatic build of Mogre
Maybe this is a task for Pyritie.

It would be great to have a full list of changes from Ogre 1.7(.3) to Ogre 1.8.
Well, as I posted above. Look here:
http://www.ogre3d.org/tikiwiki/ByatisNotes

I'm betting there are many lurkers on these forums who use Mogre that never post (like me).
An indication could be the result of the Ogre survey 2011. (here)
There were 59 votes for using C# as main development language.
I'm not shure if that are only Mogre users. Perhaps there were also Axiom users involved. (A full C# port of Ogre.)
My conclusion: Perhaps we have around 50 Mogre users.
I don't know if this is much for an open source project.
Unfortunately only 10% (or maybe up to 20%) of them seems to be active in the community.
With such low user support, there is also a smaller motivation for the active Mogre community members to do jobs for other people.
Maybe there are more lurkers, but how much should we respect users, which not even take part in an important Ogre survey? We even don't know how many totally silent Mogre users are in the world.

DirtyHippy, I don't remember your name. You had 8 posts, although you are here for 2.5 years now. But it's nice to hear your lurker voice now.

( Mogre 1.8 ) - I think, binary version should be published daily or monthly.
Daily is impossible, I think. There is nobody in the community who can spend so much time a day for Mogre if it is used only by such a small group of people.

I think the point of this is to automate the build process so that it doesn't involve any (or very little) human interaction. It's a pretty common practice to have a daily build (weekly, monthly, or whatever suits). The idea is to catch bugs earlier so they can be dealt with while they are fresh in the developers mind (among other advantages). It's a really good thing to aim for, although, the Mogre build process is far too complicated at the moment.

From a birds eye point of view it looks like the build process could be simplified and automated somewhat. Unfortunately, to do it will require significant understanding of how it works currently, or alternately, start from scratch with the same goal. There have been attempts to do this already.

At the end of the day, we start with a copy of the Ogre source code as the input and end up with the Mogre.dll as the output. Everything in the middle is how we get from point A to point B.

Mogre users were focused on their own projects.

The good news about this is, when projects require things that need Mogre to be updated, it becomes the motivation. For me personally, I've never needed anything special from Mogre so the current state of it is fine.

My main motivation for helping out is simply to make sure the project doesn't die. That's probably won't always be the case though.

There were 59 votes for using C# as main development language.
I'm not shure if that are only Mogre users. Perhaps there were also Axiom users involved. (A full C# port of Ogre.)
My conclusion: Perhaps we have around 50 Mogre users.

I doubt many Axiom users took the survey. In any case, 50 users is still enough to say Mogre is alive and important. Maybe their would be more users if we can sort out these problems. The way that question is worded also discounts people using Mogre for tools and level editors (i.e. not main development language) other such things. C# is a particularly good solution for those, so I suspect there are a few in that category (the commercial project Torchlight appears to use C# for the level editor).

I think the main problem is that I am sure many of the active Mogre users here know C++ and C# pretty well. C++/CLI not so much. Most of us are probably one man teams, and what little time we have is dedicated to working on the many problems whose solutions can be derived without having a more up to date version of Mogre. I've only worked seriously on my game for about eight months now after I ported it from C++. I cannot begin to fathom how much more efficient using C# is versus using C++. I would estimate I am at least 50% more efficient in C#. You just can't match the efficiency of writing code / debugging in C# - combine that with all the ridiculously awesome framework and language advancements it kind of boggles my mind that Mogre hasn't picked up more users over the past few years.

Unfortunately for Mogre (and Ogre), I am sure there has been, and will more so in the future, be more defections to higher level full game engines like Unity whose cost of entry is much lower in terms of technical knowledge. That being said, while I have played with Unity, and I refactored my entire system to be entirely component based ala Unity because it was just too awesome, Unity is just not fun for me. I enjoy knowing how every aspect of my engine works at all times - and frankly I love programming and solving problems too much to ever consider something else.

The other problem I have faced with Mogre is the lack of third party ports of plugins, etc. There is a ton of code that I have either A) ported from forum posts or B) rolled my own implementation of functionality already implemented in some plugin/code snippet in Ogre. It would be awesome to have some sort of automated wrapper - I would love to integrate some of that code in my Ogre build as C++ and then reference it via Mogre. At this point I am using a custom 1.7.1 port of the CandyWrapper for Physx, FMod's publically available interop interface, and Miyagi (which is incredible), so I have been able to get most of the way there by cobbling together what I can. Honestly, I wouldn't have it any other way, even given the difficulties, as Ogre is great, and the community here is great. Getting to write code in my spare time is fantastic given that during my day I am hitting F5 every five minutes on my Jira dashboard, reading funny check-in comments that my developers don't think I read, and sitting in meetings .

I am in *exactly* the same boat as DirtyHippy (aside from having developers working under me)

Cobbling together all of the bits and pieces really is the hardest part, but the end result is very satisfying. What I find is that although Unity is packed with features (which is great from a selling point of view) but it's still a lot of work using all of the features. In reality, putting together a small fun game just doesn't need it.

Anyway, that's all a bit off-topic for this thread, although, it does expose the ideal goal of all of this. Maybe it's a pipe dream, but having the ability to automatically wrap any C++ code into C#/.NET would be tremendously valuable.

That new instancing system looks awesome and I could really use something like that since my game has a ton of trees everywhere. InstancedGeometry in 1.7 is sloooow, and StaticGeometry, while it works well, chews up tons of memory

And we have a Mogre build tool. It's mostly ready, but still has some problems. Perhaps it would be useful, if someone else look to the current development state. Maybe he can solve the open gaps.
Details: Mogre.Builder - a tool for easy, automatic build of Mogre
Maybe this is a task for Pyritie.
huh what

I think the main problem is that I am sure many of the active Mogre users here know C++ and C# pretty well. C++/CLI not so much. Most of us are probably one man teams, and what little time we have is dedicated to working on the many problems whose solutions can be derived without having a more up to date version of Mogre. I've only worked seriously on my game for about eight months now after I ported it from C++. I cannot begin to fathom how much more efficient using C# is versus using C++. I would estimate I am at least 50% more efficient in C#. You just can't match the efficiency of writing code / debugging in C# - combine that with all the ridiculously awesome framework and language advancements it kind of boggles my mind that Mogre hasn't picked up more users over the past few years.Even coming from a java background and not a C++ background I completely agree about c# being awesome. Getting stuff done in it is SO much faster

Unfortunately for Mogre (and Ogre), I am sure there has been, and will more so in the future, be more defections to higher level full game engines like Unity whose cost of entry is much lower in terms of technical knowledge. That being said, while I have played with Unity, and I refactored my entire system to be entirely component based ala Unity because it was just too awesome, Unity is just not fun for me. I enjoy knowing how every aspect of my engine works at all times - and frankly I love programming and solving problems too much to ever consider something else.
Since unity forces you to use PhysX, and PhysX's vehicle stuff is pretty terrible, I'm very glad I never got into it much because otherwise switching to another physics engine (bullet in my case) would've been impossible

Since unity forces you to use PhysX, and PhysX's vehicle stuff is pretty terrible, I'm very glad I never got into it much because otherwise switching to another physics engine (bullet in my case) would've been impossible

Just as a side note while you're on the topic of physics engines. I've recently discovered BEPU physics and it is absolutely awsome. It only took me a few hours to get it integrated into my game and the character controller works right out of the box (unlike PhysX or Bullet).

Even coming from a java background and not a C++ background I completely agree about c# being awesome. Getting stuff done in it is SO much faster

It really surprises me that people often don't see the value of using C#. They think that C++ is a lot faster, but that's not really the case. Sure, you might get a 5% speed boost if you write your code correctly, but being indie developers that extra 5% boost is rarely required and never worth the extra development time. Aside from that, I guess there's 3 other problems convincing people to convert to C#. The first is that they are already very invested in what they know, there is a huge base of legacy code and there are hardly any actual games to prove it's a good option. Unfortunately, those reason's tend make a catch 22.

Wouldn't it be nice to have official support from the Ogre team for Mogre some day. After all the competition Horde3D does

Not on topic at all but an interesting read: http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf

More on functional programming than anything else but still some interesting stuff around languages, performance, and game-centric issues.

Thanks for your interesting post, which also contains personal information about yourself.

There is a ton of code that I have either A) ported from forum posts or B) rolled my own implementation of functionality already implemented in some plugin/code snippet in Ogre.
You ported C++ code to C# for Mogre?
It would be nice if you share it with our community.

Ogre is great, and the community here is great
I'm also happy about the helpful people here.

It would be awesome to have some sort of automated wrapper
About 4 years ago we has user Marioko from South America as Mogre maintainer.
He started to develop an autowrapper, which also works for add-ons.
Unfortunately his free time decreased and he became inactive.
As I wrote him an e-mail about one year ago, he said now he switched from Windows to Linux. So there is no more motivation for Mogre, because it just runs on Windows.
His autowrapper he never published. Also I don't know it's state. But I'm shure it wasn't finished, because in this case he would had published it.

Most of us are probably one man teams
Yes, most Ogre projects have only one or very few team players. I saw it in the Ogre survey 2011.

automatically wrap any C++ code into C#/.NET
The tool SWIG does this job. In the past there was OgreDotNet, which was autowrapped by SWIG. Wrapping with SWIG works (in general), but it's bad for Ogre, because it's not very performant.
Mogre is based on cpp2java and I suppose this creates more performant code. Although I don't know how much of Mogre was additionally optimized by hand.

By the way:
User manski looked deeply into the Mogre autowrapping process and created a documentation.
Related links are here: viewtopic.php?f=8&t=14817&p=83510#p83510

lack of third party ports of plugins
There are still some interesting ports and wrappers for Ogre add-ons.
Unfortunatelly I saw problems, when the creators leaved. Often other users had problems to update it. Perhaps because it's not easy to understand the code of somebody else?
Documentation is important for software development. It needs time and is not so much fun. But it's good in the long-term view.
So if some of you publish code, it would be fine to add comments to the source code.

Since unity forces you to use PhysX, and PhysX's vehicle stuff is pretty terrible
Unity was never an option for me, but I agree that using Ogre/Mogre offers much freedom of choices. The downside is that you have to do (much) more development at your own.
For my own project it was the totally right choice to use Ogre/Mogre.

I've recently discovered BEPU physics
Nice to know.

Wouldn't it be nice to have official support from the Ogre team for Mogre some day.
In general yes.
But also for this case you need at least one person with the needed knowledge and time for maintaining.
In the case that the Ogre core teams would say yes - who would do the job?



Suggestion:
It would be very good to update/publish the MogreSDK with the current 1.7 state.
In my point of view this is an important step, which we shouldn't forget, although we (seems to) focus on Mogre 1.8.

I think the build bundle of user Cygon (1.7.3) could do a good job for this. It's only .NET 4.0, but should be well for many Mogre users.
Other people have at least the choice to try the older (current) MogreSDK or to grabb or build alterternative Mogre binaries.

Our benifit:
When somebody gives Mogre a try, he shouldn't be frustrated in the first our.
He should grabb the MogreSDK (with latest 1.7 binaries), which also contains samples.
User amirabiri refreshed all Basic Mogre Tutorials and wrote a new and good Tutorial Framework. So it's a good starting point.
If new users have a good first impression of Mogre, they are more motivated to use it. Perhaps later they develop and share improvements.
If new users are frustrated in the first our (because of bad SDK/binary support) or they don't just touch it (because it looks outdated), then we have bad chances to find new community members.

More on functional programming than anything else but still some interesting stuff around languages, performance, and game-centric issues.
Looks interesting. I pushed it to my printer and read it when I go by train.
But for today I will go to bed. I wanted to go one our ago, but reading/replying to this topic tooks longer.
See you later my friends

Suggestion:
It would be very good to update/publish the MogreSDK with the current 1.7 state.
As written in some other topic I started to update the SDK or better I started to compile all dependencies from scratch and will compile latest versions of Ogre + Mogre.