Creating a new Mogre - Help wanted

Dear community,

maybe you have followed the discussions that came with the new Terrain and Paging component for us Mogre users (check this topic starting at page 5). It took a pretty long time until we were able to use it even mstoyke provided the first version months ago. It's still alpha state and unfortunately nobody besides him can finish the wrapper and we are not able to develop the next version of Mogre (actually Mogre 1.8 should be on the way ). He himself has not much time for Mogre anymore because he is focussing on other things in his life.
So the community has to take action to keep Mogre alive. Therefore we should start right now with some questions:

Who wants to help?
The only important things are the will, motivation and time. Knowledge of C++/CLI is not neccassary, a lot of the work will also be compiling and testing. The more people are willing to help the best they can the easier it will be for everybody.

What do we want?
What shall the "new" Mogre be like? Because of the fact that the current way Mogre is built is not fully known to anybody we will probably have to make some changes.

What features do we want for Mogre?
Some time ago mstoyke created a "wishlist" that is created by the community and manages the goals the Mogre development has. This enables the maintainer to focus on things that are really needed by somebody and not wasting time by implementing features that nobody is interested in. This list can cover core functions but also addons and plugins.
That's how mstoyke described it:
Because we usually don't really get much feedback here, the last release of Mogre is still in beta because of lack of feedback, I want to try something new. I will create a list of things that I can't do myself at the moment and the first users that provide solutions for the task will be preferred for some time in the Mogre wishlist.

So more active users will get their feature requests done much quicker than others. That is actually an improvement in the development process, because usually, in open source project, most developers work on what they like most, not what others might need. So this is an opportunity for everybody to improve Mogre and the features that you need will not be delayed because nobody wants to work on them.
That's how the old list looked like, just to get an idea...
The current prioritized list is:

1. (+9) Ogre terrain component wrapper (details here)
   [/*:m]
2. (+7) Miyagi (add-on for GUI)
   [/*:m]
3. (+5) MOIS update (add-on for input) (done)
   [/*:m]
4. (+5) Updated SDK (improved installer)
   [/*:m]
5. (+5) Documentation updates
   [/*:m]
6. (+4) More example projects
   [/*:m]
7. (+4) MHydrax (add-on for water simulation)
   [/*:m]
8. (+4) Ogre paging component wrapper (part of the new terrain system for large terrain)
   [/*:m]
9. (+2) PhysX candy wrapper (add-on for physics + collision detection)
   [/*:m]
10. (+1) MogreNewt (add-on for physics + collision detection)
    [/*:m]
11. (+1) MyGUI wrapper (add-on for GUI)
    [/*:m]
12. (+1) FMOD SoundManager (add-on for Sound)
    [/*:m]
13. (+1) CEGUI
    [/*:m]
14. Using Particle Universe with Mogre (wiki)[/*:m][/list:u]

I am excited to hear all your comments

What sort of things would we have to do?

EDIT: to elaborate, what do you mean by "compiling and testing"? Taking builds of mogre, making test programs, and seeing if they work?

What sort of things would we have to do?

EDIT: to elaborate, what do you mean by "compiling and testing"? Taking builds of mogre, making test programs, and seeing if they work?
Yes, taking precompiled binaries and test them, especially for new features, but also compiling Mogre itself and detecting problems. Often the maintainers can provide new source code but have only local binaries. So we also need people who are willing to grab the sources, compile them and report errors if any. This way not everything depends on one maintainer.
Other things could also be maintaining the Mogre SDK for example.

Thanks McDonte for your motivation to support Mogre.
It's not easy with a small team and less free time.

I don't think we need a "new" Mogre. We just need to update it.
There will be a wiki page with porting notes (new features and API changes).
Perhaps it's still there. Look here:
http://www.ogre3d.org/tikiwiki/ByatisNotes

Also it would be useful when anybody solves the bugs.
I published bugs many months ago, but unfortunately nobody created a fix. Some bugfixes would need only tiny changes. But it should be done on the right place. (Where is the right place?) So that the autowrapper process keeps the changes and doesn't overwrite it.
Here is the bug tracker / feature request list:
http://bitbucket.org/mogre/mogre/issues

Mstoykes "prioritized list" is not that old. Every time when somebody give his vote, I updated the list. Unfortunately there was no vote for many months. (Or did I miss it? I will check it.)

Cygon did a great job. He created a fresh Mogre build (1.7.3) and updated the depencies. Also he compiled some add-ons and offered x86/x64 binaries.
The binaries are in this topic: Some x64/x86 builds of Mogre 1.7.3

I think it would be good, if we could update the Mogre SDK. Now it's about 2 years old (Mogre 1.7.1).
There we should add Cygons binaries and add the new example applications. (I added some to the SVN, but the setup builder doesn't know. Also they should be tested before adding.)
The very long forum topic (with suggestions and bug reports) is here:
http://ogre3d.org/addonforums/viewtopic.php?f=8&t=11703
If somebody has a real interest to spend time on an SDK update, I could read the whole topic and grabb all posts, which are still useful. But I don't want to do the job, if it's for nothing.

Sorry for not answering to my own topic sooner but since sunday I am in Kazachstan and here I do not have very good internet connection.

First, sorry to disagree, Beauty, but since we are not able to use the Autowrapper we have to wrap Ogre again. Maybe with the same method Mogre uses but we have to do it again from scratch (or write a new autowrapper...). You can call it different but in my opinion it's basically "creating a new mogre". The porting notes are actually helpful but they are written in a very general way, not really detailed.
Cygon did a great job. He created a fresh Mogre build (1.7.3) and updated the depencies. Also he compiled some add-ons and offered x86/x64 binaries.
The binaries are in this topic: Some x64/x86 builds of Mogre 1.7.3
Yes, but the problem is he created them only for .net 4 (this was actually his motivation). If we want to support .net 3.5 too then we will have to recompile all again, otherwise you will end up with mixed assemblies. Or we decide to drop .net 3.5 to focus onto Mogre 1.8.

I do not want to argue, if there are more people who say "mogre just needs a little update", I will follow. But for the moment we are not able to do this update, at least from my point of view and knowledge.

Sorry for not answering to my own topic sooner but since sunday I am in Kazachstan

Don't worry. It's no problem if answers need a few days.
I hope you enjoy your time in Kazachstan. Don't hang around too much in the internet. Be happy about your trip.


First, sorry to disagree, Beauty, but since we are not able to use the Autowrapper we have to wrap Ogre again.
I suppose it's more difficult to wrap Ogre from the scratch again.
Also it would need stability tests.

Well, there is not much knowledge about the wrapper internals.
My ideas:
* About 2 years ago user manski looked deeply into the wrapper source (without previous wrapping knowledge) for about one week and then he could anderstand how it works. When he got it, I suppose others have the same chance, too.
* We could ask Bekas (the original author of Mogre) for documentation - although I don't know if he has time and motivation for this.


Cygon did a great job. He created a fresh Mogre build (1.7.3) and updated the depencies.
Yes, but the problem is he created them only for .net 4
You are right, I forgot.
On the other hand I suppose it could be a good template for a .NET 2.0/3.5 version, too.
The changes should be lesser than re-wrapping Ogre.

If we want to support .net 3.5 too then we will have to recompile all again, otherwise you will end up with mixed assemblies.
Or we decide to drop .net 3.5 to focus onto Mogre 1.8.
Recompiling everything again should be more easy than re-wrapping Ogre.
As I understood, Cygon created/published a project which contains all sources and depencies.
This could be a good starting point for an 1.8 update and also a good starting point for an other .NET version.
In best case we would just need 2 different VS solution files to create 2 different .NET versions.
But it's only theory. I have no practical experience, because I never tried to build Mogre.

After manski analyzed the Mogre wrapper, he made changes/additions to the code.
He also wrote a wrapper documentation.
Look to this post for further details:
viewtopic.php?f=8&t=14817&p=83510#p83510

Has anyone given Cygon a prod to see if he could help with this at all?

Unfortunately he Cygon wasn't logged in to our forum for 3 months now.
He updated Mogre "just for testing".
It's one of at least 3 options for his 3D project.
If he decide for an other "3D environment", then it's bad luck for us.
Yes, we could ask him, but I suppose he will only do tasks, which are also useful for his own project.
In best case he decide for Mogre and need new features of Ogre 1.8.
I will ask him for his current state.

update:
I aked him in this forum post.

Hi!
I know C#, .Net, C++ (and many other languages) and am using Mogre in a
spare time project for about 1 year now. I do not have much time, but I would
be willing to work some time on mogre itself.

So basically - I am in;)

But I do not want to read all the several forum pages, just to get started - So I
would need someone (maybe McDonte) who gives me the basic information,
coordinates the development and is taking the "project lead".

And about the discussion - I really appreciate the work you are all doing to keep Mogre
alive, but for me it is totally irrelevant if its called "new Mogre" or "updating Mogre". We
want to always have the newest Ogre version wrapped and with as little development effort
as possible, right? So lets get started;)

And about the discussion - I really appreciate the work you are all doing to keep Mogre
alive, but for me it is totally irrelevant if its called "new Mogre" or "updating Mogre". We
want to always have the newest Ogre version wrapped and with as little development effort
as possible, right? So lets get started;)
I think you said exactly what we are all thinking but no one has yet said and what is actually the important point!

So basically - I am in;)
But I do not want to read all the several forum pages, just to get started - So I
would need someone (maybe McDonte) who gives me the basic information,
coordinates the development and is taking the "project lead".
I will summarize all information as soon as I can, at the moment I have nearly no internet connection and it is pretty hard to write something here... but I will just prepare my post offline I guess it will be by the end of the week maybe next.

How Mogre is working:
Mogre is basically a C++/CLI wrapper for Ogre. You can find this technique also used for other projects (Managed Hydrax for example). Usually for every C++-class there is a C++/CLI-class generated and the second class can access the original class but also provides an .NET interface that can be used from within C# or VB.NET.
The difference for Mogre is that the Ogre sources are modified and a couple of classes are inherited from a class called CLRObject. The Mogre classes do not need to deal with the original classes directly but everything is done via this CLRObject. This process has two big advantages:

1. Performance: Mogre and Ogre are actually intersecting each other and can control the creation of objects in a way that avoids the creation of objects that are already created.
   Apply the CLRObject patch. This adds some fields into public Ogre classes
   that will be used by Mogre to look up the managed wrappers (so when the Ogre
   API returns some object, like a texture, for which a managed wrapper already
   exists, Mogre can just look it up and return the existing wrapper).[/*:m]
   
2. Creation of the wrapper: a usual C++/CLI wrapper has to be written by hand, there is no chance to do this in an automatic way. For Mogre there is the AutoWrapper tool that creates all Mogre classes we need. This tool needs some information about the used Ogre sources that are collected by the tool cpp2java. This is actually an adaption of Doxygen that produces plain information about the Ogre sources.[/*:m][/list:u]
   
   How Mogre is updated:
   Thanks to the above described procedure of the wrapping process the most work is updating the AutoWrapper tool. Sometimes we need to update the source code itself (don’t worry, it’s all C#) or we need to update the configuration files for cpp2java to include new sources files (for example new components or plugins). At last the modification of the Ogre sources needs to be adapted by a simple patch file that is extended for new classes that need CLRObjects.
   Take a look here for an example of the changes mstoyke made to create the first version of the wrapper for the terrain and paging component.
   
   How Mogre is wrapped (in short):
   
   1. The Ogre sources are adapted.[/*:m]
      
   2. The Mogre sources are created.[/*:m]
      
   3. Ogre is compiled without Mogre.[/*:m]
      
   4. Mogre is compiled.[/*:m]
      
   5. Ogre is compiled with Mogre.[/*:m][/list:u]
      
      What is to do now?
      The main problem is that the AutoWrapper tool is not documented and we need to update it to be able to produce Mogre 1.8. At the moment it runs fine for Ogre 1.7.3 (but not with Ogre 1.7.1 or 1.7.2). It is possible that we can use it without modifications for Ogre 1.8 but I am not sure about that.
      Additionally we need to finish the wrapper for terrain and paging that mstoyke started. Unfortunately we do not know what needs to be done and what is already done. As described earlier it is not just source code but lots of configuration files that are all not documented. How this needs to be done can might be found out by looking at the changes for the last Mogre release.
      
      Now we were all arguing about what to do to Mogre. Basically we all want Mogre 1.8 with working Terrain and Paging. I think there are maybe five people who are willing to help by getting active themselves. This should be enough to have the work done but the question is where to start. And how to start. About Cygon's binaries: they are up to date to Ogre 1.7.3 and providing working terrain functionality. Unfortunately they are only covering .Net 4.0.
      
      So, tsr, I hope that answers all questions so far and you do not have to read all forum posts
      
      
      
      (All what I know and write here I have found out by myself by looking at the Mogre sources and while trying to compile it on my own. If I am wrong somewhere and you know better please correct me!)

Mstoykes "prioritized list" is not that old. Every time when somebody give his vote, I updated the list. Unfortunately there was no vote for many months. (Or did I miss it? I will check it.)
Sorry, I didn't see that you were updating it. Maybe it should be moved to the wiki since it's getting lost here in the forums...

I think it would be good, if we could update the Mogre SDK. Now it's about 2 years old (Mogre 1.7.1).
Well, I am working on it. I am basically doing the same as Cygon but I will provide builds for all .net versions. So far I have compiled most of the dependencies but am stuck compiling some libraries/binaries for x64 with toolset vc90. Unfortunately the Visual Studio 2008 Express version does not allow compiling x64 applications... I have to install Windows 7 SDK first

There we should add Cygons binaries and add the new example applications. (I added some to the SVN, but the setup builder doesn't know. Also they should be tested before adding.)
The very long forum topic (with suggestions and bug reports) is here:
http://ogre3d.org/addonforums/viewtopic.php?f=8&t=11703
If somebody has a real interest to spend time on an SDK update, I could read the whole topic and grabb all posts, which are still useful. But I don't want to do the job, if it's for nothing.
You do not need to read it, I will do it myself since compiling all this stuff will take a long time

Hello community

I've been following the various topics surrounding Mogre development and the terrain stuff on and off for a while now. I've only just discovered this topic so forgive my late entry into the discussion. I'd like to contribute, the main problem I see at the moment is that we don't have a clear set of tasks. Has anyone here used an Agile Task Board before? I've used them on a couple of projects and they are a really simple way to keep track of what needs to be done.

Essentially you have a bunch of high level tasks called stories that describe the goals of the project. Then, you break each story down into smaller post-it note size tasks and put them into the TO-DO pile. When someone is doing the task it goes into the DOING pile and then moves into the DONE pile. Along the way you'll probably find more tasks to add to the TO-DO pile that you didn't think of at the start.

Maybe this kind of this won't work exactly that way for an open distributed project like Mogre because people will come and go and the tasks will be left unfinished. I guess we just need to be careful to leave tasks in a state that can be taken over, either that or the task gets started again from scratch.

Anyway, based on what I've read so far I think the stories break down like this:

- Build a new Mogre binary using the Ogre 1.8 source code.
- Build the Terrain and Paging component to work with Mogre 1.8.

It sounds like McDonte has already done a bunch of work (thanks mate) and determined that one of the tasks is to rewrite / fix the AutoWrapper tool. I'm cool with that, but unfortunately I still don't really know what needs to be done. If I was going to approach this task right now, I'd probably go through the whole process that McDonte has already done to figure out what's next.

McDonte, can you shed some more light on the tasks that have been done? What comes next? And do we need to setup some kind of repository to share source code and notes?

Okay, so in my spare time today I thought I'd get started to get a better idea of what we are in for. I didn't get all that far, but here's a quick summary of what I did do:

1. I downloaded the Ogre Source 1.8 RC1 Executable from http://www.ogre3d.org/download/source
2. After unzipping it I started reading through the BuildingOgre.txt file
3. I also needed to download cmake (win32 installer), OgreDependencies (vs package)and the DiretX SDK (Jun10)
4. After installing each bit according to the instructions and wrangling with cmake a little I managed to generate at VS2010 solution.
5. I built the debug version and tried to run the resulting SampleBrowser_d.exe file. There was some error about a missing dependancy dll.
6. I found the missing dll and dumped it into the folder, now it runs and some of the samples work. The terrain sample hangs for a long time and I eventually have to end task (maybe this is just my crap work machine though).

So, only a tiny bit of progress today, but my hope is that by reporting progress it'll get everyone on the right track.

The terrain sample hangs for a long time and I eventually have to end task (maybe this is just my crap work machine though).
You can try to build OGRE with boost (http://www.boost.org/) then the terrain sample and Ogre::Terrain should be a lot faster.
When you have some trouble with compiling boost you can try a prebuild package from here http://www.boostpro.com/download/

You can try to build OGRE with boost (http://www.boost.org/) then the terrain sample and Ogre::Terrain should be a lot faster.

I tried it again later and it eventually did work. The sample was only slow to load everything else seemed okay. While we are on the topic though, I read somewhere that Mogre can't be built with boost? Is that still true?

Building Ogre was relatively easy, but it was still very time consuming and it's only the first part of the whole Mogre build process. If we are going to get the process of building Mogre easier we'll need to either strip out some steps or have very clear easy to follow instructions.

I think we can build Mogre with boost -> viewtopic.php?f=8&t=7826&start=0
This is important because without boost Ogre::Terrain is so slow that we can not use it. I had the same problem in the past with Ogre 1.8 and a Ogre Build with boost has solving this problem.

I wanted to compile Mogre with boost anyway for the SDK but I had no idea what it is useful for Thanks for the link to the topic, I read it and the solution seems to be very simple. Am I right, that the user does not need to care about the usage of boost sicne it is done by Ogre itelf?

I tried the terrain in Mogre with the Ogre 1.7 binaries and it was running pretty good. What has changed in 1.8 that makes boost neccassary? I read somewhere that paging is nearly not usable in 1.7 because of it's performace. Maybe the changes are related to this fact...

Only problem we are facing with that:
Once Mogre is compiled, add the Boost precompiled dlls to your runtime directory (otherwise you will get a "FileNotFoundException")
This will result in an even larger number of dll files in your application folder. If we could manage to compile these dlls/libs into Ogre/Mogre it would be great...

Am I right, that the user does not need to care about the usage of boost sicne it is done by Ogre itelf?
Yes that's right, OGRE is using boost for it's internal multithread support as far I can see.

I tried the terrain in Mogre with the Ogre 1.7 binaries and it was running pretty good. What has changed in 1.8 that makes boost neccassary? I read somewhere that paging is nearly not usable in 1.7 because of it's performace. Maybe the changes are related to this fact...

I think that's because the GSoC 2011 changes in the Ogre::Terrain component. When I run a Scene which uses the Ogre::Terrain Component with Ogre 1.7 (without boost) the loading speed is much more faster then the loading speed with an Ogre 1.8 Build (without boost too).

This will result in an even larger number of dll files in your application folder. If we could manage to compile these dlls/libs into Ogre/Mogre it would be great...

I wouldn't worry about this right now. The priority is to get it working the easiest way possible.

I finally managed to build Mogre using the MogreBuilder. Detials over in this thread.