Updating Mogre! [Mogre 1.8.1 was build successfully]

Pitancos

26-01-2014 23:27:19

Dear community,

I myself have used Mogre some time ago (2-3 years), but I had never enough time to join in and contribute to the project. As I can see, right now there is little or even no progress around this project. This is pretty sad, I think, as Mogre is a great wrapper for an awesome engine. So I would like to start the process of updating Mogre!
If there are already people working on it or would like to join me, let me know, the more the better :D

I would like to propose the following roadmap:
  1. Mogre 1.7.4[/*:m]
  2. Mogre 1.8.1[/*:m]
  3. Mogre 1.9.0[/*:m][/list:u]
    The version numbers are related to Ogre for clearness. I would spare out all versions between these major releases as long as the community doesn't have the power to react to every Ogre update. Minor releases are only useful for a small amount of people and are probably easy to achieve with some small modifications to the wrapper. But having some major versions in a stable precompiled state and is useful for a lot of people.

    I would like to re-new the SDK with binaries for...
    1. .NET 3.5 and .NET 4[/*:m]
    2. x86 and x64[/*:m][/list:u]
      These four different versions are needed because that's what people are asking for the most (as far as I can see from the forums). Besides of that it is not really an effort to provide them as it is just recompiling with other options in Visual Studio. I would also like to update some of the addons (most of it should only be recompiling and some minor adaptions). Personally I really would like to see the Hydrax wrapper working again :wink:

      Now I would like to know from the community: What do you think of it? Shall I give it a try or not waste my time?
      I know, that's quite ambitious but even if we get just a little bit started it may helps others to continue this awesome project!

Zonder

27-01-2014 08:10:54

I don't think anyone is actively working on this and it definitely is getting to the stage something needs to be done.

I think you have it all there and definitely keep to stable releases. Only thing I would advise is do this in a fork so you can issue pull requests / other people can issue pull requests on your work also then.

se5a

27-01-2014 18:14:48

Excelent!
I'd offer to help if I knew what I was doing.
also note that to many, the plugins are as important as mogre itself.

Zonder

28-01-2014 08:03:52

Excelent!
I'd offer to help if I knew what I was doing.
also note that to many, the plugins are as important as mogre itself.


one step at a time ;)

Plugins shouldn't be a priority in the whole scenario also unless the plugin has been upgraded to the version of ogre its not going to work anyway (I think the common ones are though)

Pitancos

29-01-2014 15:08:32

Only thing I would advise is do this in a fork so you can issue pull requests / other people can issue pull requests on your work also then.
I will start with this, thanks for the advise :)

I'd offer to help if I knew what I was doing.
Testing builds and reporting errors will be a big help already :wink:
Besides of that I myself will have to learn a lot about all the custom wrapping process and so on, so do not consider me an expert for the insides of Mogre.

Plugins shouldn't be a priority in the whole scenario also unless the plugin has been upgraded to the version of ogre its not going to work anyway (I think the common ones are though)
I see se5a's point but I agree with you. Though they extend Mogre at several points the core is more important at first. But many will only require recompilation and some small adaptions I think.

Also: you guys are talking about addons not plugins, don't you? :D

se5a

30-01-2014 02:16:31

I mean things like MOIS, and ParticleFX, those are two I'm using in my current projects.
considering MOIS is used in a the tutes, that's kind of a big one.
It kind of becomes a chicken and egg thing.
but yeah, got to start somewhere.
yup testing I can do.

Zonder

30-01-2014 08:11:32


Also: you guys are talking about addons not plugins, don't you? :D


Yes that's what I meant! ;)

Plugins don't need wrapping ogre loads them in the C++ world. They do need compiling against the MOGRE version of OGRE though as the wrapping processes changes the OGRE dll.

se5a

30-01-2014 08:34:10

ah. so plugins such as particleFX are trivial if it's all built at the same time? I guess with mogre builder that makes things easy.
MOIS on the other hand could be harder, though would much change between the versions?

One request I do have if I may, is that billboards gets looked at, specificaly the ability to SetTextureCoords without having to use an unsafe{} block. (currently it wants a pointer)

Zonder

30-01-2014 10:52:27

MOIS should work as it's not dependent on OGRE it's just an input library. I am not sure on usage for particlefx if it doesn't need a wrapper to access it's methods now then it won't on an upgrade.

Beauty

02-02-2014 00:49:54

Picantos, thanks for your offer and energy.
Use MogreBuilder to build the modified Ogre and the Mogre wrapper.
It's a great tool.
Feel free to improve it, when it's useful for you.

I can give you useful links for your plans, but not today.
See you later again.

Beauty

02-02-2014 20:40:00

Ok, I searched for related information, which I posted in the past.
Have a look to this topic: MOgre 1.8 1st attempt

Here is a quote of my post there:
I whish you good luck.
Especially I say thank you so much for your efforts in figuring out the problems and your reports.
Unfortunately I can't help, because I have too less knowledge in this topic.

In the case that you don't know a specific forum topic, have a look here:
Understanding the Mogre build process


User Caprico has some first experience with Ogre 1.8. Maybe you can combine your forces?
Here is a related post of the topic [MogreBuilder] My mission to build a better Mogre

I started to work on this. I already ported the ClrObject patch. It applies cleanly against the current Ogre 1.8 source but doesn't include any of the new classes in 1.8 yet. MogreBuilder still crashes sometime later in the build process. Didn't found the time to look into this further.
I uploaded the patch file here, in case somebody else wants to try too.


And here is a suggestion of me:

I think it's a good idea to create a second branch for Ogre 1.8 related improvements.
This is good for team orientated development and doesn't disturb the 1.7 build process.
When the 1.8 branch works stable/successful, we can merge it with the default branch.



Ascendion, which version of TortoiseHG / Mercurial did you use for your MogreBuilder builds?
The latest one?
I ask, because there were problems with a specific version (TortoiseHG 2.4.3, Mercurial 2.3).


But we definitly need to wrap all stuff of ogre 1.7.* BEFORE we are working on mogre 1.8.* .
Yes, it would be fine to have all new 1.7 features in Mogre.
Now we had about one year for improvements. I think it's no good idea to stick on the waiting level like a deadlock. :mrgreen:
I think it's no barrier to put efforts to Ogre 1.8.
I'm happy to see that someone improves the Mogre core.


There some missing classes and known bugs (shared ptr issue, "unwrapped" void* pointers, ...).
I didn't know that there are bugs.
Tubulii, it would be nice if you add the known bugs to the Mogre issue tracker. (If not done yet.)
Additionally you could publish the names of the missing classes to an other issue report.
This would be good for the further development.




I would like to re-new the SDK with binaries for...

* .NET 3.5 and .NET 4
* x86 and x64

I don't think x64 is important for most users. If somebody needs it, he can compile it by the -64 option of MogreBuilder and include the binaries to his project.
To the SDK repository I added some examples, but they aren't included to the Mogre SDK installer (inno setup scripts).
An other point: Which Visual Studio version should be offered? VS 2010 or 2012 or both.
More options means more work for creation and maintaining. Additionally it's multiplied with other options.
To offer all options would mean: .NET version (2 option) x x86/x64 (2 options) x 2 VS version = 8 types of the SDK.
It's much work.
The SDK is especially for beginners. So I thinks it would be useful to just offer one or two kinds of SDK. Maybe .NET 4.0 + x86 + VS 2010/2012.
By the SDK newcomers can learn the Mogre basics. If somebody knows them, it should be no problem for him to get a solution for the other wanted options.

Shall I give it a try or not waste my time?
Of course!
If you have time and motivation it's always good to have active supporters.
I don't need Mogre for over one year now, but still want to support the Mogre community. Even when I don't have so much time.

I would also like to update some of the addons
You want to do much. Ogre update, add-ons update, SDK update ... this is too much for one person at one time.
My suggestion: Focus on that point, which you like to do the most.
As I sad: Play around with the MogreBuilder. It's a very useful tool. Inside of the code you get some ideas how it works internally.
First, just run it to build mogre and have a look to the downloaded and generated files. It's easy and get you a feeling about.
Good luck.

se5a

03-02-2014 01:37:40

if you're going to only offer one VS version, then go with the newer. especially since 2013 is now out and hot.
on the other hand, VS will update a 2010 project to 2012.

I *really* don't like the tute sdk thing. I think it hampers beginners rather than helps, since it's hiding a bunch of the basic stuff away in a dll, basic stuff that the tutes should be teaching first. Currently as soon as a beginner wants to do something not tutorial related, and skim down to the bare bones, they have to go looking for the sdk source and try figure it out on their own. but I digress, it's a subject for another thread.

Beauty

03-02-2014 08:04:00

Idea for SDK:
We could include more than one VS project files to the SDK. So we still need only one installer.
The newest ist not always the first choice, because VS costs money. I know that not everybody (private or company) has the latest version quickly after its release.

DLL in SDK?
Do you mean the mogre framework?
I think is was not the best choice of user Amirabiri to hide the code in a dll file.
Better would be to add the code as second project to the VS solution file.
So users can look to it, learn from it and have an easy way to apply changes.

Advantages of the SDK:
The depencies will be installed, compatible binaries are available and example projects.
It's not needed to search for all the stuff in the internet.
Yes, the basic tutorials should be the first experience for beginners.

se5a

03-02-2014 18:02:09

True, I've never used the professional version, only express so I've typically kept up to date.

Yeah meant the tutorial framework, yes having it as a project would be far better.
having the tute walk people through setting up this project would also be good.

What dependencies are needed to be installed? it's been many years since I did it. one of these days I'll have to set up a VM or something with a fresh windows install just to see what is bare minimum needed to get an mogre project started.

Beauty

08-02-2014 12:26:19

Depencies of Mogre

What dependencies are needed to be installed?

1.
At least the latest updates of DirectX 9. Although the version number didn't change for a long time, Microsoft published updates.
So the Mogre user needs at least that DirectX 9.0c status, which was used to compile Mogre.
Easy solution for end users: Just download and run the DirectX web installer.

2.
When VS compiles code, it also uses special DLL files. They are installed by VS automatically to a system directory.
When a computer starts a software (compiled by VS) and doesn't find the special DLL files on the system, you get strange exceptions and doesn't know the real reason.
Solution: Install the "Microsoft Visual C++ 20xx Redistributable". Often the installer file name is just "vcredist.exe", althouth there are different versions.
Which version has to be installed? Maybe one, maybe more.
First the version, which was used to compile Ogre/Mogre.
Second the version, which was used to compile your project (which includes the Mogre.dll file).
Third: When your project uses additional dll files (e.g. a physics engine), which were compiled by VS, then you need to install the related vcredist version.
Note: VS with and without service packs needs different vcredist versions. (e.g. if you have a VS 2010 SP1 project, which uses a DLL file compiled with VS 2010 (without SP1), then both vcredist setups are needed to run your application.)

If any software of your computer installed a vcredist version (e.g. for VS2008 SP1) before, then your own project can use it, too.
Several software installers contains the related vcredist setup and install it silently in the background.
So it can be, that your application can run on a random computer without additional call of vcredist setup.
Sounds complicated? Yes, it's a little bit tricky.

In best case all dll files of your project were compiled by the same VS version (or without VS).
You know it, when you compile everything on your own. The MogreBuilder should help.
It also helps to compile Mogre add-ons, because you find all needed depency source files in the MogreBuilder output directory.
Then you just need to ship one vcredist setup file with your application.

Here are the downloads:
Visual C++ Redistributable Packages for Visual Studio [b]2013[/b]
Visual C++ Redistributable for Visual Studio [b]2012[/b] Update 4
Microsoft Visual C++ [b]2010 SP1[/b] Redistributable Package (x86)
Microsoft Visual C++ [b]2010[/b] Redistributable Package (x86)
Microsoft Visual C++ [b]2008 SP1[/b] Redistributable Package (x86)
Microsoft Visual C++ [b]2008[/b] Redistributable Package (x86)
Microsoft Visual C++ [b]2005 SP1[/b] Redistributable Package (x86)
Note: Don't install the x64 version (even when you have Win 64 bit), because Mogre is by default compiled against x86.
Only if you compile your project (and all depency DLLs) against 64 bit, you need the x64 installers instead.
A 3D guru (user mstoyke) wrote, that there is no real benefit, when you create a x64 Ogre/Mogre application.


The Microsoft Visual C++ 20xx Redistributable Package installs runtime components of Visual C++ Libraries required to run applications developed with Visual C++ on a computer that does not have Visual C++ 20xx installed.



3.
The graphic card driver should be updated.
Sometimes there can be trouble if the drivers are too old.
By the way: I read that Intel graphic cards cause trouble from time to time. Also some mobile GPUs.
Solution: Use a desktop PC with an AMD or nVidia card. :mrgreen:

4.
The related .NET framework(s) should be installed.
If you install .NET 3.5, you can run applications, which were compiled against .NET 2.0, 3.0 or 3.5.
If you install .NET 4.0, you can run applications, which are compiled against .NET 4.0.
I suppose you also can install .NET 4.5 to run applications, which are compiled against .NET 4.0.
The related installer download pages you can search yourself (-;

5.
All needed Ogre and Mogre binaries should be available.
An easy way is to add them directly to your Mogre project.

I think there are no more depencies.

True, I've never used the professional version
I don't remember details, but the full versions of VS have realy useful advantages.
If you are a student: Maybe you can get VS for free, because Microsoft has agreements with many universities.
By my experience from companies I know: Even if they want to upgrade to a newer VS version, it needs some time.
In general it's often common to use "old" licences for a longer time, because it costs money.

se5a

09-02-2014 18:09:09

Thanks, that's quite usefull information.
much of that though you wouldn't or can't put in the sdk.

I would debate the point that there's not much benefit of an x64 version when you can't know what the non graphics/rendering part of the application is doing. though I agree that it shouldn't be a high priority - as long as it's not overly tough for someone to build an x64 version themselfs.
On that note though, what would it take to get it to compile for "AnyCPU"? I've noticed that you can compile a debug version for "AnyCpu" but compiling a release is where it will break.


Yeah, the full version of VS allows plugins, and some tools for working with a larger team. though I've yet to come across any that would make me fork out that much $ for the full version, especially as I'm just a hobbyist programer.

BrainScan

09-02-2014 19:18:40

This is interesting timing. I recently ran into a problem with compositors in 1.7.4 that required me to update Mogre. I've spent the last few days working on it and I now have 1.8.1 "working". Essentially, I had to disable the Paging and Terrain Components and the new Instance Manager to get it to compile initially. But I have it up and running with my current project now. I have some cleanup to still do and there will be some breaking changes but it looks promising.

What exactly is required for contributing these change back? I know the main Ogre project requires a contributor agreement be filled out. Anything like that here?

I'm not familiar with Hg at all for source control, so it make take me some time to be able to push any changes. Do we need a new branch? Should the auto-wrapper be able to wrap both versions or do we stop development on 1.7.4 and just move forward?

What about the license? When Mogre was started the main Ogre project was still licensed using the LGPL. Now Ogre has switched to the MIT license, but most of the Mogre files still have LGPL headers.

se5a

09-02-2014 20:00:07

Excellent News!

Beauty

09-02-2014 20:25:01

On that note though, what would it take to get it to compile for "AnyCPU"?
When you compile with AnyCPU, then VS uses that type (x86 or x64), which is equal to your operation system.
So compiling with 64 bit Windows: VS tries to compile a project against x64.
And x86 for 32 bit Windows.

When VS tries to build against x64 and your project contains 32 bit libraries, then you'll get trouble.

Yeah, the full version of VS allows plugins, and some tools for working with a larger team.
There are also improvements for "normal users".
For example to set conditional breakpoints. (Example: Break only if value xx is larger than 100.)
There are also other debugging improvements. Just to let you know that the people get something more for the money.

se5a

09-02-2014 20:31:20

express has conditional breakpoints in 12.

Beauty

09-02-2014 20:38:06

I've spent the last few days working on it and I now have 1.8.1 "working". Essentially, I had to disable [...]
But I have it up and running with my current project now.

Great news !!


What exactly is required for contributing these change back?
I know the main Ogre project requires a contributor agreement be filled out. Anything like that here?

I never heard about such an agreement. Maybe it means if somebody can't use LGPL he could ask for an agreement.
But this is many years ago. Ogre (and Mogre) switched to MIT license to make the live easy for all users.

My proposal:
Download the current Mogre repository and create a new branch (e.g. name "Mogre 1.8").
Then commit all your changes and upload the modified repository to your BitBucket account.
So everybody can see your changes and it's easy to push them to the official Mogre repository.
If you have good experience with Mercurial, I can offer you write access to the official Mogre repository.

I'm not familiar with Hg at all for source control, so it make take me some time to be able to push any changes. Do we need a new branch? Should the auto-wrapper be able to wrap both versions or do we stop development on 1.7.4 and just move forward
... I should read the whole posts, before I answer.

A new branch would be very useful.
There are good chances, that the Ogre 1.6 branches get updates in the future. There are still some things to do (e.g. terrain has no full support and is less tested).

Now Ogre has switched to the MIT license, but most of the Mogre files still have LGPL headers.
Just ignore this point. The reason is that nobody changed it. I suppose it's a boring job.


Did you use the MogreBuilder?
If yes, did you apply changes / additions to the code?

Beauty

09-02-2014 20:47:14

there will be some breaking changes
It would be nice if you write some details.
Are the changed caused by Ogre (API changes) or something related to the Mogre wrapper?

BrainScan

11-02-2014 00:04:31

Download the current Mogre repository and create a new branch (e.g. name "Mogre 1.8").
Then commit all your changes and upload the modified repository to your BitBucket account.
So everybody can see your changes and it's easy to push them to the official Mogre repository.

I created a BitBucket account and forked the repository. I still need to find a nice Hg client for windows and figure it all out. That will probably need to wait until I've finished polishing up the 1.8 stuff that I need immediately for my current project. I might start with pushing some of my 1.7.4 improvements just to get my feet wet a bit.

Did you use the MogreBuilder?
If yes, did you apply changes / additions to the code?

I've never used MogreBuilder, so I'm not sure what changes would be needed. Perhaps someone who knows MogreBuilder could make the required changes once I've pushed the 1.8 branch.

there will be some breaking changes
It would be nice if you write some details.
Are the changed caused by Ogre (API changes) or something related to the Mogre wrapper?

Any Ogre breaking changes will certainly be inherited by Mogre. For my project the new Depth Buffer sharing caused a bunch of weird stuff to happen with my compositors and RTTs until I set the depth buffer pools correctly. There were also some method signatures that changed on the Ogre side. I'm not sure if there's a comprehensive list anywhere.

As far as the wrapper goes, so far I've had to make some minor changes to the way properties are wrapped to get some of the new stuff to generate properly. This could have made some existing code also generate properties instead of get and set methods. I haven't run into any in my code, but it should be easy to fix since it will cause compile-time errors.

se5a

11-02-2014 00:40:55

I still need to find a nice Hg client for windows and figure it all out.

I use http://tortoisehg.bitbucket.org/

which is not horrible, as far as these things go, which isn't saying much really.

Beauty

11-02-2014 07:35:12

Yes, TortoiseHG is a great graphical front end.
But HG and the front end need some learning / experience to undestand how it works.
There are good tutorials and overviews in the web. Unfortunately I don't have my bookmark collection here.

Well, polishing up your code is fine and your project has a higher priority than publishing. But please don't forget us.

Even if you don't need MogreBuilder, it could be a nice experience for you to download, compile and run it.
It takes about 5 or 10 minutes to start the automatic build process.
You don't need to modify it - that can be done by us.

The porting notes are always published in the wiki. For Ogre 1.8 look here:
http://www.ogre3d.org/tikiwiki/ByatisNotes

Thanks for your details and good luck for your further work.

Pitancos

12-02-2014 19:49:32

Cool news! :D But one question, BrainScan: you said you removed the terrain and paging components, do you plan to include them again? I think they are a really important part of Ogre 1.8+. Especially the paging system can be really powerful.

I don't think x64 is important for most users. If somebody needs it, he can compile it by the -64 option of MogreBuilder and include the binaries to his project.
I think it is important, I saw several times people asking here on the forums for x64 binaries. While building Mogre it is pretty easy to build it both x64 and x86 as it is just one more step in CMake (create OGRE x64 build files) and some more compilation. The only change is it takes twice as long to compile but that doesn't make much of a difference anyway :P I put my focus on the "common" x86 binaries and only do the other ones if there is no more effort involved. As x64 is getting more important in the future (at least I think so) we should be prepared.

An other point: Which Visual Studio version should be offered? VS 2010 or 2012 or both.
I am using VS 2012 Professional (benefits of being a student :D ) but I think it would be best to provide solutions/projects for VS 2010 too. VS 2013 is not needed yet, I think, so far I have not seen it being provided by OGRE etc.

You want to do much. Ogre update, add-ons update, SDK update ... this is too much for one person at one time.
You probably missunderstood, I do not want to really dive into the code of addons but I want to recompile and distribute them for the new Mogre binaries. If there are just some small changes to be made that's fine as well. But definitely not full support for addons, that would be too much, you're right.


What I got so far is Mogre binaries for Ogre 1.7.4 which are still "experimental" as I just grabbed the source code and didn't do any changes. There are two problems I am facing right now:
  1. What is missing for Mogre 1.7.4? The terrain and paging component are wrapped but are they fully working? Samples do work, I know and tested, but what is still missing? Which features are missing that exist in the corresponding Ogre version? I took a look at the bug tracker but those are not especially problems relating to the current version (meaning no missing features) but general bugs (should be fixed anyway).[/*:m]
  2. Does anyone ever had the error LNK2034? I appears only when I am compiling Mogre for .NET3.5 in debug mode (both in x86 and x64), the release mode works fine. It is poorly documented or I am just too stupid to find the right sources on the internet...[/*:m][/list:u]

    @BrainScan: It would probably really useful if we combined our forces to avoid work being done twice :wink: I sent you a pm, check it :)

    At last, I am glad there is still interest in a new Mogre version, so I will do my best to contribute something :)

se5a

12-02-2014 21:04:29

This is a bit of a 'for the future' question, and I don't in anyway know the full implications (I realy have no idea what I'm talking about) but I went looking at why mogre can't run on linux or mac.
Basicaly this is due to mono not supporting C++/CLI - then I stumbled across CXXI.
Would it be worth looking at CXXI in the future for mogre? (I supose it would require a compleate rewrite :( but might it be worth it if it alows cross platform suport?)

Edit: reading a bit more, it seems that CXXI was looking very promising a few years ago... then nothing.
though looks like this branch of it has had activity six months ago: https://github.com/tritao/CppSharp

BrainScan

13-02-2014 03:08:52

Cool news! :D But one question, BrainScan: you said you removed the terrain and paging components, do you plan to include them again? I think they are a really important part of Ogre 1.8+. Especially the paging system can be really powerful.
I removed them because they were causing problems and I don't actually use them in my project. For whatever reason the way they were integrated before required them to be included in order for Mogre to load properly. This eliminates the whole point of them being components. In my opinion, what has to happen first is to figure out how to optionally include and build components in general. This would have to include the ability to choose which components are being wrapped though the AutoWrapper. This will be increasingly necessary as time goes on. For example, in 1.9 the overlays were removed from OgreMain and put into their own component.


What is missing for Mogre 1.7.4? The terrain and paging component are wrapped but are they fully working? Samples do work, I know and tested, but what is still missing? Which features are missing that exist in the corresponding Ogre version? I took a look at the bug tracker but those are not especially problems relating to the current version (meaning no missing features) but general bugs (should be fixed anyway).

There doesn't seem to be a good list of what is missing in 1.7.4. The approach I have taken is to try and wrap things as I need them. I suspect a better approach would be to analyze the output of doxygen and somehow compare it to what is wrapped. One thing on my TODO list is to organize the Attributes.xml so I can get a better picture of what's missing. But that's a nightmare for later merges so I haven't gotten around to it yet.


Does anyone ever had the error LNK2034? I appears only when I am compiling Mogre for .NET3.5 in debug mode (both in x86 and x64), the release mode works fine. It is poorly documented or I am just too stupid to find the right sources on the internet...

I'm only targeting .NET 4.0 with my projects so I've never run into this.

BrainScan

13-02-2014 03:17:36

Edit: reading a bit more, it seems that CXXI was looking very promising a few years ago... then nothing.
though looks like this branch of it has had activity six months ago: https://github.com/tritao/CppSharp

The main repository for that project is now part of Mono and is located here: https://github.com/mono/CppSharp
It seems to get regular updates but still has some limitations and experimental features. Most notably is the standard library support which Ogre uses quite extensively. It looks very promising for the future though since it can generate C++\CLI for windows targets and P\Invoke for linux.

se5a

13-02-2014 03:44:08

that does sound promising. we'll definatly have to keep an eye on it.
how much work would it be once it's got the required fetures in it to convert mogre over?

BrainScan

13-02-2014 04:46:33

I haven't had a chance to play around with it, so I'm not sure how much work it would be. My guess is it would be hard to keep the interface the same, so there would be breaking changes. Also, one of the key features of Mogre is that it maintains a strong link between a native object and a managed object so that you always get back the same managed object for a given native one. That's why we have to apply patches to ogre and recompile it specifically for Mogre. As far as I can tell CppSharp doesn't do that. I'm not sure what kind of performance issues that may cause. Let alone what kind of bugs it would cause in existing apps using Mogre.

When it comes down to it, I just haven't been able to justify spending time looking into it since it's such an experimental task. I was originally planing on holding out for Ogre 2.0 and then giving it a try.

Pitancos

13-02-2014 11:09:33

I removed them because they were causing problems and I don't actually use them in my project. For whatever reason the way they were integrated before required them to be included in order for Mogre to load properly. This eliminates the whole point of them being components. In my opinion, what has to happen first is to figure out how to optionally include and build components in general. This would have to include the ability to choose which components are being wrapped though the AutoWrapper. This will be increasingly necessary as time goes on. For example, in 1.9 the overlays were removed from OgreMain and put into their own component.
This problem is related to the nature of Mogre. If you are using Ogre you only need to include the libraries for terrain, paging or overlays if you are actually using them. For Mogre the wrapped parts of these components are also in the Mogre.dll so the OgreTerrain.dll etc. is always loaded on startup. I think you could solve the problem just by splitting the Mogre.dll into smaller dlls for the components e.g. MogreTerrain.dll, MogreOverlay.dll etc. As far as I can see this would not require changes to the AutoWrapper as the Mogre VS project and solution are manually created.

I suspect a better approach would be to analyze the output of doxygen and somehow compare it to what is wrapped.
By that you mean the output generated by cpp2java? (which is technically doxygen) I had a look at the generated xml files but that's really painful with several thousand files.

I'm only targeting .NET 4.0 with my projects so I've never run into this.
Only .NET 4 would be nice and easy but I think 3.5 should be still supported. Unfortunately it doesn't go well with VS2012 and C++/CLI for some reason so I have to think of something else...

This is a bit of a 'for the future' question, and I don't in anyway know the full implications (I realy have no idea what I'm talking about) but I went looking at why mogre can't run on linux or mac.
Basicaly this is due to mono not supporting C++/CLI - then I stumbled across CXXI.
Would it be worth looking at CXXI in the future for mogre?

I wanted to start exactly this discussion in another thread but as we already started: Mono support would be great, yes, and probably really good for Mogre as it becomes usable to more people but it's hard to achieve. C++/CLI is just not working on Mono (at least not the way we are using it). Unfortunately there are not so many other options to bring native code to manged. One you have already mentioned, CXXI.

The main repository for that project is now part of Mono and is located here: https://github.com/mono/CppSharp
It seems to get regular updates but still has some limitations and experimental features. Most notably is the standard library support which Ogre uses quite extensively. It looks very promising for the future though since it can generate C++\CLI for windows targets and P\Invoke for linux.

I was not aware that there is still life in the project. That makes it really a potential option, though we need to check if it can be used for our purpose at all.

The only other options there are (or I have herad of) are P/Invoke (with a project that big this can only be done by some helper utility like SWIG) or some COM way, though I have never seen a really good way to implement it (also, Mono and .NET differ on the usage and implementation). Both would probably cause a complete rewrite of the wrapper...
Are there other options?

Beauty

13-02-2014 20:27:01


it is just one more step in CMake (create OGRE x64 build files) and some more compilation.

Yes, but what I mean: I wouldn't offer additional x64 versions of the MogreSDK. The SDK I would just offer as x86.


I do not want to really dive into the code of addons but I want to recompile and distribute them for the new Mogre binaries. If there are just some small changes to be made that's fine as well. But definitely not full support for addons, that would be too much, you're right.

This would be useful and doesn't need so much time.
But be aware: Some add-ons like the Hydrax wrapper seems to be more difficult to be updated.


In my opinion, what has to happen first is to figure out how to optionally include and build components in general.

I suppose this is done by options, which are processed by CMake. (Just a suggestion, I never checked it.)


For example, in 1.9 the overlays were removed from OgreMain and put into their own component.

Good point. (Although I don't understand, why overlay classes were outsourced.)

It would probably really useful if we combined our forces to avoid work being done twice
Yes, it's nice to work as a team.

At last, I am glad there is still interest in a new Mogre version
I don't need Mogre anymore, but still want to give you support. Especially by information, which I collected all the years. (Much of it I already added to the Ogre wiki.)

so I will do my best to contribute something
Good boy !!

Would it be worth looking at CXXI in the future for mogre?
There was a discussion about in the Mogre forum (year 2011). Look here:
viewtopic.php?f=8&t=15032
http://www.ogre3d.org/forums/viewtopic.php?f=1&t=68227

I supose it would require a compleate rewrite
Maybe it would be possible by "just" modifying the Mogre wrapper tools.





The terrain and paging component are wrapped but are they fully working?

User mstoyke added support for the components, but he wrote that only a part of the features are supported yet. Some functionality he disabled, because it caused trouble with the wrapping process and he didn't had the time to figure out the reasons. I don't know the terrain and paging components are much tested. At least I didn't read much feedback in the forums.


What is missing for Mogre 1.7.4?

In the Mogre issue tracker I found this:
https://bitbucket.org/mogre/mogre/issue ... tormanager
https://bitbucket.org/mogre/mogre/issue ... rcemanager
https://bitbucket.org/mogre/mogre/issue ... e-material

As far as I know the class(es) for parsing Ogre config files aren't supported.
Because of this I wrote an own code for parsing the config files of the Caelum add-on. (That files have the same syntax as material files.)


Does anyone ever had the error LNK2034?
I never saw this.

how much work would it be [...] to convert mogre over?
I suppose you only know it when you try it. Nobody knows how much trouble you get on the way.
Maybe it's relatively easy work, maybe it's a hell.

Also, one of the key features of Mogre is that it maintains a strong link between a native object and a managed object so that you always get back the same managed object for a given native one. [...] As far as I can tell CppSharp doesn't do that.
Before Mogre there was a project called OgreDotNet.
It used SWIG for autowrapping, which created managed objects without reference to the native Ogre objects.
Because of this the code often created new "copies" of native objects instead of just updating the corresponding managed objects.
The result: It was very slow. (I don't know how much slower.)
I never tried OgreDotNet, but this is what I read in the forums.
If it's the same for CXXI / CppSharp, then this would be bad.

That's why we have to apply patches to ogre and recompile it specifically for Mogre.
It's nice to see that you looked deeper into the Mogre autowrapping process.

For Mogre the wrapped parts of these components are also in the Mogre.dll so the OgreTerrain.dll etc. is always loaded on startup.
The MogreBuilder is a great tool for this job. I just need some additions to offer switches for that.
Then everybody can create binaries for their own needs (without special knowledge about Mogre internals).

[Missing features in Mogre 1.7.4]
I suspect a better approach would be to analyze the output of doxygen and somehow compare it to what is wrapped.

I got an idea: Have a look to the XML config file, which is used by the Mogre autowrapper.
Path: Codegen \ AutoWrap \ Attributes.xml
There features disabled by "ignore" lines like this:
<class name="ScriptToken" Ignore="" />

One thing on my TODO list is to organize the Attributes.xml
I should read first before I write. (But then there is a danger, that I'm to lazy to read everything again.)

But that's a nightmare for later merges so I haven't gotten around to it yet.
You could clone the repository and additionally create a branch. Then you can do experiments without creating a nightmare to the original repository (as long as you don't push the changes to your main working repository).

Only .NET 4 would be nice and easy but I think 3.5 should be still supported
I remember that there were requests in the past to keep support of older .NET versions.
Maybe the reason is that .NET 4 (and newer) uses an other "background framework". Version .NET 2.0 upto 3.5 uses the same framework.
Mixing DLLs of .NET 4 and older ones is possible, but I read it can cause trouble. So all additional components (dll files) of a users application should use the same framework. Maybe there are older components without .NET 4.0 binaries (e. g. because the development is stopped).

Unfortunately it doesn't go well with VS2012 and C++/CLI for some reason
Good to know.

Unfortunately there are not so many other options to bring native code to manged.
One user wrote his own game engine, based on Ogre and other specialised engines.
It's also supported by Linux and Mac.
How he did it?
He wrote the whole wrapper by hand (everything!!). His wrapper used P/Invoke.
This would be no good way for us. But it's possible.

Ok, I wrote much again (for about 2 hours). Thanks for reading.

Pitancos

13-02-2014 22:17:23

So...I took a look at CppSharp, even compiled it from the sources but ended up with using precompiled binaries as there were syntax errors or something. My conclusion so far:
  1. I love the way the tool works :D you are just writing a C# class that has the information about the library you want to wrap, then pass it to the generator and it generates the wrapper. Really elegant I think.[/*:m]
  2. Unfortunately it is not working for Ogre (or at least for me).[/*:m][/list:u]
    I think, the problem is that Ogre is "too complicated" as it is using a lot of preprocessor definitions, templates and so on. Also std classes like vector, list, map and so on are apparently causing problems (the documentation states so), I am even getting a NullReferenceException somewhere in the CppSharp dll when it tries to wrap an std::vector.
    Next big problem: boost. When I tried to run CppSharp with boost enabled in Ogre I just got one class from the boost::unordered namespace wrapped everything else was dropped. So I recompiled Ogre without boost but that just produces other errors.

    Maybe it is related to the state of the project but so far I do not see how to get CppSharp working with Ogre. Though the reason for that could just be that there is not enough documentation and discussions yet, so I could google a little bit around and find solutions for my errors. If anyone got further than me please let me know how you managed to do.

    Yes, but what I mean: I wouldn't offer additional x64 versions of the MogreSDK. The SDK I would just offer as x86.
    There I agree, that would be a lot of extra work and the SDK would become pretty large. But for plain binary releases I would target both platforms.

    Maybe it would be possible by "just" modifying the Mogre wrapper tools.
    If we would switch to another way of wrapping Ogre to .NET I think most Mogre code would be not needed anymore since every system is working totally differently and for CXXI/CppSharp all what we have now is not needed (e.g. Clang is used for parsing the source code not cpp2java/doxygen).

    I got an idea: Have a look to the XML config file, which is used by the Mogre autowrapper.
    Path: Codegen \ AutoWrap \ Attributes.xml
    There features disabled by "ignore" lines like this:

    I already looked at it but just the ignore option does not help to find missing features. It is used a lot all over currently fully wrapped parts. As the file is not or not really well documented this will be a hard task.

BrainScan

14-02-2014 07:34:05

So...I took a look at CppSharp, [...] Unfortunately it is not working for Ogre (or at least for me).
I suspected as much. It seems to me that CppSharp lies firmly in the "Promising, but not ready yet" domain. So, for now at least, I'm going to stick with the current Autowrapper way of doing things.


I got an idea: Have a look to the XML config file, which is used by the Mogre autowrapper. [...]
I already looked at it but just the ignore option does not help to find missing features. It is used a lot all over currently fully wrapped parts. As the file is not or not really well documented this will be a hard task.

The Attributes file is quite a mess. I'd like to reorganize it so its at least sorted alphabetically by class name. Hopefully that will make it easier to see what's missing. Part of the problem is that a lot of stuff gets rejected by the autowrapper tool without the need for an Ignore tag in the Attributes file.

It's nice to see that you looked deeper into the Mogre autowrapping process.
Yes, I have become very familiar with most of the internals over the last year. Though, there's a lot of poorly documented code and there's still some very confusing bits.

You could clone the repository and additionally create a branch. Then you can do experiments without creating a nightmare to the original repository (as long as you don't push the changes to your main working repository).
I want to get a stable 1.8 version with at least the same functionality of 1.7.4 before I go doing a lot of experimenting.

edoardo

14-02-2014 15:46:06


What exactly is required for contributing these change back?
I know the main Ogre project requires a contributor agreement be filled out. Anything like that here?

I never heard about such an agreement. Maybe it means if somebody can't use LGPL he could ask for an agreement.
But this is many years ago. Ogre (and Mogre) switched to MIT license to make the live easy for all users.


I know about that agreement because I signed it when I proposed a patch some years ago, it applies only to the main Ogre project and it's required by the Ogre Team to contribute code in the official repository.

Nothing like that for Mogre, as Beauty can confirm...

Cheers

se5a

14-02-2014 18:22:31

It's awsome that we're looking at cppsharp and cross platform options.
pitty it's not quite there yet, I agree that maybe waiting for ogre2 might be best, I'd expect ogre2 has breaking changes itself.
although, I personaly don't think breaking changes is too much of an issue, and well worth it for cross platform capability.
Whether there's a significant performance drop will have to be looked at though. when ogre2 is a bit further along (is there any reson to wait till its 'released'?) we could maybe ask around cppsharp comunity, maybe we'll get lucky and somone there will be interested enough to help out, and spark further development in cppsharp with problems we're having.

CagedFury

09-03-2014 19:19:57

So I just downloaded MogreBuilder from source, built it and configured it for

MogreRepository = @"https://bitbucket.org/BrainScan/mogre";;
MogreBranch = @"Mogre18";
OgreRepository = @"https://bitbucket.org/sinbad/ogre/";;
OgreBranch = @"v1-8-1";
ClrPatchFile = @"Main\Ogre Patches\mogre-1.8.1-clrobject.patch";

Then ran it for vs2012 & MOIS. All seems to be successful, nice work man :)

BrainScan

12-03-2014 00:48:46

Great to hear its working well for you. If you happen to play around with any of the new 1.8 functionally like the InstanceManager, please report back. I don't think anyone has tried it out yet. If you find anything missing let me know.

Also, I'd like to compile a list of addons that are known to be working with 1.8. So if you're using any successfully, please let us know.

Thanks!

RMI

20-03-2014 09:34:44

Wonderful job :D

Beauty

05-05-2016 13:34:52

I wasn't here for a long time.
Now I read this thread again and looked to the Mogre repository.
Nice to see that you, BrainScan, merged your sweet improvements to our official repository. Thanks! :D

BrainScan, why did you close the branch TerrainAndPaging? (Changeset c8d2bd3)
As far as I know there were Mogre improvements (additionally to the Ogre components), which were applied only to the TerrainAndPaging branch.
Are they already transmitted to the active branches?
If not, we should add a task for this in the issue tracker.

Piotrek

29-05-2016 20:22:48

Hi guys!
This discussion froze around 2014.
So what is the actual status of Mogre 1.8.
Where can I download compiled version?

Beauty

29-05-2016 22:00:25

There was no further development since the work of BrainScan.
You can use MogreBuilder to compile Mogre. It's easy to use.

Have a look to some posts above. There a user wrote the needed changes for the MogreBuilder config file.

Piotrek

29-05-2016 23:50:09

Thanks Beauty!
Are you aware if this version is stable? Does it support DX10/11 ?

Mogre looks like an abandoned project. It is a little unfortunate because it is one of the best solutions for .net platform:(

Beauty

30-05-2016 08:08:22

You can use Mogre 1.7 or 1.8. It's not the latest Ogre version, but still powerful.
I don't know the stability of Mogre 1.8, because I don't develop 3D stuff anymore. (Nevertheless this was a great time.)
Mogre 1.7 was stable for me and many others.

Well, there was a bug in Ogre (not Mogre) for years, which caused frequently a deadlock to my application. But this only happened in very special cases and only with the Terrain Scene Manager.
By the advantage of open source I could figure out the problem, fixed the bug and re-compiled/re-wrapped Ogre/Mogre.

Mogre 1.7 and 1.8 supports DirectX 9.
I suppose many users doesn't need new features of DirectX 10 and 11.
Even in C++ Ogre they needed long time for DirectX 10/11 implementation. I'm not sure, if it's already full implemented in the Ogre engine.

So if you don't need a special DirectX 10/11 feature (e.g. tesselation), then just try Mogre 1.7 or 1.8.
For example take my 1.7 binaries:
viewtopic.php?f=8&t=29714

In my point of view Mogre 1.7 has the advantage that it contains the Terrain Scene Manager.
In Mogre 1.8 it's removed, because it was removed from Ogre 1.8 to push the new Terrain Component. (Note: The wrapper for the Terrain Component is more experimental).

Aside of this, our user boyamer starts to develop a new wrapper for Ogre 2.x.
But I can't tell you when it's ready and I can't promise that it will be ready. (I think the chances are good, because boyamer is a developer with good experience.)
Just follow his topic: Mogre for Ogre3D 2.0.

I suppose Ogre 2.x is still in beta stage. The Ogre 1.x versions are well sophisticated over the years.
So I suggest not to look to release date too much.

If you want to know the advantages of Ogre 2.x, look here:
http://www.ogre3d.org/about/what-version-to-choose

Piotrek

30-05-2016 12:44:32

The main reason for moving into DX10/11 are problems that I have encountered with debugging hlsl. On newer Windows system you cannot enable shader debugging for DX9. So PIX is useless, and I think there is no alternative for debugging dx9 shaders than moving to Windows 7 without some updates installed (KB2670838). This would allow to debug with PIX and dx9.

P.S. It is sad to hear that you are no longer developing 3D :(

randomcode

18-08-2016 09:48:27

where can i download it?