Mogre 1.7.1 (old thread)

.
.
.
This Mogre 1.7.1 is read-only now.
Use the new Mogre 1.7.1 thread instead.

There you also find the current download links.
.
.
.
------------------------------------------
Mogre 1.7.1 is out ! This version is compiled against the 1.7.1 version of ogre, related to the 2130 revision in mercurial repository.

Also, a big thanks to mzanin, who have made this possible, fixing problems i have encountered

* SDK beta available here : Mogre SDK 1.7.1
* For vs2010, you can use the files from mstoyke available here : Binary for vs2010
Please give us a feedback! Report successful uses, bug and questions here! (note added by Admin Beauty)

The objective is to update it on a regular basis, and to add new plugin and feature that haven't make it in this version.

The source code is available in the svn, as always, but this new version build process has additional step that have complicated an already complex setup . It's planned to change it to make it easier for the end user.

Know issues :

1. DistanceLodStrategy and PixelCountLodStrategy don't work for now.[/*:m][/list:u]
   
   If you have questions, suggestions or feedback, please post here.

Congrats!

* HardwareBufferManager (...) don't work for now.
I hope that's resolvable, cause I need that thing.

Oh, and looks like some virus scanners spit out false alarms for dependencycheck.exe:
https://www.virustotal.com/en/analisis/ ... 1271362530

I hope that's resolvable, cause I need that thing.

yeah, that's definitely the next thing on the todo list .

Oh, and looks like some virus scanners spit out false alarms for dependencycheck.exe:
https://www.virustotal.com/en/analisis/ ... 1271362530

I know that the dependencycheck have been rewrited recently, i will check this out with the author

I managed to fix the issue with HardwareBufferManager (cus' I need that thing too )
I'll check in the changes sometime soon.

wow,it's a landmark.

About the dependency checker: this is a common issue with executables compiled using the Tiny C Compiler. The dependencychecker.exe file is completely clean, but I don't have any idea to stop these false alarms.

This site says:

False positives occur when a pattern of code in the file matches the same pattern contained in a virus signature. This can occur due to a faulty signature or it can occur after improper disinfection by the same or different antivirus scanner.


But I don't see how to find out the pattern that causes the alarm...

By the way:

Prevx 3.0 2010.04.15 High Risk Worm

No.

BTW, you can find the "official" SDK here.

This is good news indeed. Congrats GantZ. I'm gonna test it soon.

new version released. this one wrap the 1.7.1 version of ogre. it's also the return of the hardwarebuffermanager

See first post for updated download link.

Niiice thank you guys for keeping Mogre running!

I'm having troubles with the Mogre Basic Tutorial0 at this site

I have remove for now Mogrenewt and Mogreframework files, since i haven't compile them against this new version, i will add them later.

so I don't have Mogreframework.dll now...
what I want to know is that how can I start "Basic Tutorial 0" without Mogreframework...
what should I do?

Try tutorial 5. It has all the basic stuff you need to get a mogre programm running.

I havent used the mogreframework, so I dont know what one will be missing. But i think together with the framelistener tuorial one is good to go

Otherwise, here mogreframework.dll compiled against 1.7.1 :

[attachment=0]MogreFramework.zip[/attachment]

I will upload a new sdk with missing library later on.

Thanks alot~

Does VS2010 support in this version? Could you also just as binary?

Oh, and looks like some virus scanners spit out false alarms for dependencycheck.exe

This is a bad issue and not good for our image. We know it's clean, but I suppose newcomers could be afraid to catch a virus and possibly doesn't install the SDK. So a new Mogre user could be gone again.

I know that binaries comprimized by UPX often get false positive. Look if the tiny C compiler uses UPX and if so, then disable it.
On the other hand - maybe an other C compiler could be used?

By the way - nice to see that you still continue the Mogre development (-:

Link to the most recent VirusTotal result (16/41):
http://www.virustotal.com/de/analisis/e ... 1274700440

Funny thing: It's not packed with UPX, but if you do compress it, it only gets recognised by 11 scanners:
http://www.virustotal.com/de/analisis/2 ... 1274701418

I've already reported the false positive to AntiVir, Panda and Sophos (the other ones are pretty obscure).


Btw, thanks for the HardwareBufferManager fix. Works like a charm.

Still, this issue is pretty annoying, my virus scanner won't stop nagging about the file, i can't even install the sdk properly on other computer (some virus scanner delete dependencychecker as soon as they found it).

I think about using an other compiler, but it should avoid the need of external dependencies. I don't know too much about c compiler, i have think about trying out mingw. What do you think ?

Yeah, go with MinGW:
http://www.virustotal.com/en/analisis/c ... 1274743233

I didn't know what's MinGW. If somebody else doesn't know, look here:
http://en.wikipedia.org/wiki/MinGW
http://www.mingw.org
Good idea, smiley (-:

Well, it was Gantz' idea, not mine.

The attached zip contains the binary and a modified source code file.
The dependencies of the binary seem to be the same as for the TCC complied one.

I have uploaded a new mogre sdk, same link than before. This version add the mogrenewt and mogreframework lib, as well as the dependencychecker compiled against mingw

@Smiley80

I have tested you version, but it keep telling me that i haven't the vc++ redist installed (i use windows 7 x64). I have include your modifications and add a check for the redist, hope it can take into account all windows version.

I have uploaded binary of mstoyke for vs2010 to sourceforge. see first post for the download link.

Hey, I've noticed some posts about failed dependency checks, which i've recieved constantly for VC++ sp1 (which is most definitely installed). Mogre seems to install nevertheless, but (i'm an ogre newb) i tried the sample files and none of them could be found. Precisely the same thing happens on two very different computers. Please, why the hell is this happening? My third year comp sci project is suffering! Please someone wise and illuminated help me. Should i stick with 1.4.8? Or is this too old and unsupported? Should i go with 1.7.0? I don't know....

could you be more precise about the problem you got with samples ? The dependency checker got some issue with finding vc++ 2008 redist, but that don't have any influence with app using mogre. Also, could you provide some informations about the config where the checker fail ?

wow! thanks for the prompt reply! When the sample screen appears, and i select one, then attempt to run it, i recieve:

"Error processing command
(X) There was an error processing your command. The error returned was: "The system cannot find the file specified"."

Also, as far as the depenency checker is concerned, it yields no details (unless i just don't know where to find them); only leaves the checker box on the screen with vc++ 08 the only thing with it's checkbox un-ticked. Every time i try to tick it to upgrade, it takes me to the link, and prompts me to download and install that which has been repeatedly downloaded and installed already. Should i perhaps be seeking a more stable version og mogre? For that matter, why is there such a huge gap between 1.4.8 and 1.7.1? Should a newb be just oh so careful when selecting a version of mogre ie avoid anything between 1.4.8 and 1.7.1 exclusively?

well, there is no specific gap between the 1.4.8 and 1.7, the problem here lie with the checker. It seem you try to run a sample, but haven't build it yet. to build the samples, go to the mogresdk folder and run "BuildSamples.cmd" (use "BuildSamplesX86.cmd" if you are on a x64 os). After that, you should be able to use the sample browser.

the only difference is the 1.7 sdk is more subject to update. the 1.7 is still in beta mainly because some new additions introduced with 1.6/1.7 haven't be wrapped / don't work /haven't be tested yet. but you could do the same with the 2 version. Also, with 1.7, you can take advantage of the latest bug fixes to ogre/mogre. Frankly, i don't see any advantage to keep using 1.4.8 nowadays if you haven't an application that already use it.

Mogre 1.4.8 is very old (maybe 2 or 3 years).
The SDK gap ist because since 1.4.8 the SDK maintainer doesn't work in our community. Some monts ago one of our good boys created a new and improved SDK that should help newcomers. The SDK installer and its content is still a beta version, because there are still some things to improve (like fixing your bug). Additionally the system environments on several computers are different.
So your feedback is welcome to help us.
Which operation system do you have? (Windows XP/Vista/7 / Linux / Mac ... 32/64 bit)
Which Visual Studio version you use? (2005/08/10 ... free Visual C# or a commercial studio version)

I just tried swap to Mogre1.7, I have donloaded and installed SDK.
After trying to build my application i got the following errors.


Error 7 Property or indexer 'Mogre.BillboardSet.MaterialName' cannot be assigned to -- it is read only

Error 9 Argument '2': cannot convert from 'Mogre.SceneNode' to 'Mogre.IRenderable'

Error 19 Property or indexer 'Mogre.BillboardChain.MaterialName' cannot be assigned to -- it is read only

Error 22 'Mogre.VertexData' does not contain a definition for 'Clone' and no extension method 'Clone' accepting a first argument of type 'Mogre.VertexData' could be found (are you missing a using directive or an assembly reference?)

Error 24 'Mogre.VertexDeclaration' does not contain a definition for 'Clone' and no extension method 'Clone' accepting a first argument of type 'Mogre.VertexDeclaration' could be found (are you missing a using directive or an assembly reference?)

Error 25 Property or indexer 'Mogre.SubMesh.MaterialName' cannot be assigned to -- it is read only


And I have got the following questions:

Mogre.BillboardSet.MaterialName / 'Mogre.BillboardChain.MaterialName' / 'Mogre.SubMesh.MaterialName' <-- Why we do not keep this property get/set

Is 'Mogre.SceneNode' not 'Mogre.IRenderable' anymore because of Ogre 1.7 ?

'Mogre.VertexData' / 'Mogre.VertexDeclaration' no "clone" method anymore why ?

lost in the land of ogre...

i'm running win7 64 with vs2008pro sp1 and appear to have successfully installed the sdk 1.7.1, can build and run items, but they all begin with a runtime library error exclaiming:

Assertion failed!
Program: ...
File: ..\..\Ogre\OgreMain\src\OgreRoot.cpp
LIne: 112

Expression: ms_singleton

For more info on how your program can cause an assertion failure, see the VC++ documentation on asserts.

(Press Retry to debug - JIT must be enabled.)

I ensured JIT is enabled, which it already was, re-ran, hit 'retry' at the error, and then faced a featureless black window, with an appropriate title, but nothing doing.

C'mon ogre, where's the support?

which installation instructions does one go by when installing mogre 1.7.1 in order to achieve success?
Alternatively you can try the Mogre 1.6.5 SDK. Mogre 1.7 is still very fresh and maybe has some unsolved problems (or API changes?). Mogre 1.6 is stable and maybe the SDK works better.
http://code.google.com/p/mogresdk/downl ... e&can=2&q=

Did you install the newest version of DirectX?
To be shure, please start the DirectX web installer. You can download it here:
http://www.microsoft.com/downloads/deta ... laylang=de

Please look to the file ogre.log. It can contain warnings and errors. If so, then post it.


Why do are all the tutorials and official installation instructions so out-dated? It seems rather odd for such a popular product...
It's a pitty that the tutorials are so outdated. This can happen with open source projects. There is no specific maintainer and everybody has an other focus of work and time.
Yes, Ogre is famous and has a big community. But in the Mogre section (C# users) are not many people who maintain the project. The development is going on, but unfortunatelly not the tutorials. I know - it's not nice

I would very much appreciate if there was a Mogre version build against OGRE with double precision enabled. I have experienced som precision issues and find it rather difficult to set up the environment from scratch to do the build.

I saw the original download, didn't get far with that one, noticed the official 1.7 installer thing - tried that, but it fails miserably - it was built with Any CPU when it doesn't really work for x64? I don't even know what its issues were, the debug projects are linked against release assemblies, so can't even quickly load and run the first project without updating references... but then I have to set the default CPU to x86?

all my systems are x64

- retract : I do have a x86 system I have this atom netbook... runs some of the installed SDK pretty well - the environment mapping demo is 150fps; textuer demo at 100fps; transparency about 70fps; at full screen 1024x600x32; can't get the bsp demo to work... or skeltal ainimation, or any other - the working list was shorter.

So ya, you know really Any CPU and x86 really compile the same meta code, thre's just some magic loader bits... there's a way to set the app.config file to be tend to x86 operation.

--------------

Oh reading more - was gonna go pick up the binary 'stable' 1.6.5 but note that that thread ends with this same information.

I'm not shure, but if I remember right, then you need to set the 32 bit option to the compiler. Then it works even on 64 bit systems.
Just try it. More I can't tell you about. Maybe someone else.

Here is a bugreport from a new user. It was a little bit hidden on an other thread:

Also: Neither of these pages has an active bug tracker. How is one supposed to file a bug for this project?

Specifically in my case (using Mogre 1.7.1 beta): Mogre.Math.Sin(0.0f, true) throws a DivisionByZero exception but Mogre.Math.Sin(0.0f, false) doesn't. The same is true for "Cos(0.0f, true)".

Update: Neither of both functions seem to work at all when using lookup tables - no matter what angle is specified.

Update2: Found out that one needs to create a new instance of "Mogre.Math" to initialize its static trig table lookup functions to work. (WTF?) It's not done automatically for whatever reason.

Hi,

I used Ogre before and now I'm investigating to use Mogre,
I have a list of questions, if they shouldn't be posted here plz tell me:

1. 
   1) Is there any date planned for the official release of Mogre 1.7.1
   2) I checked the assemblies for VS 2010 (target framework 4.0). Some of them (i.e.: Mogre_d.dll, MOIS.dll, MogreFramework.dll) still have the .net framework 2.0 (v2.0.50727) as target framework, is there any reason for this? Will this be updated in the future?
   3) Are there some general rules about the performance hit of using Mogre compared to Ogre?
   4) Assume I start using Mogre, is there any guarantee MOGRE will exist in the near future (so follow the roadmap of Ogre)?
   5) I saw an article on using Mogre inside WPF (http://www.codeproject.com/KB/WPF/OgreInTheWpf.aspx). Is that important for the Mogre team (do you investigate this? do you recommond this?) Are there other options for communication between Mogre and WPF (not an option to change this, part in WPF is already created)?
   6) I already got a working Mogre application, but I can't seem to get the debugging working in VS 2010? Do you have to configure/change something?
   7) I thought DirectX10 and DirectX11 where already supported? Is this correct because the assemblies RenderSystem_Direct3D10.dll and RenderSystem_Direct3D11.dll seem to be missing?
   [/list:u]
   
   Thanks in advance,
   
   Yannick

3. After you have created your scene there is no performance hit at all (since it's a wrapper). There is probably lower performance when creating objects since you got additional layer .Net <--> Ogre but it is so small that it's unnoticeable. Also when you are using listeners you have to pass throught this layer. I would go with Mogre your application will never have a bottleneck on a .Net <--> Ogre layer.

I used Ogre before and now I'm investigating to use Mogre
Nice to see you

1) Is there any date planned for the official release of Mogre 1.7.1
The question is: When you decide to say a software is stable? I suppose after the update to the current Ogre kernel the 1.7 wrapper got the beta status. When several people try it in their applications without problems, then it's fine. When there are problems, we hope they post it here. Mogre will be actively developed / updated. But we need feedback by others. We welcome to give Mogre a try and post your problems when you have some

2) I checked the assemblies for VS 2010 (target framework 4.0). Some of them (i.e.: Mogre_d.dll, MOIS.dll, MogreFramework.dll) still have the .net framework 2.0 (v2.0.50727) as target framework, is there any reason for this? Will this be updated in the future?
With this I have no experiences, but in an other thread I read that .NET 4.0 can use .NET 2.0 libraries.


3) Are there some general rules about the performance hit of using Mogre compared to Ogre?
For this I can only tell you my personal thoughts.
The core library is still the same Ogre. The difference to Mogre is, that the applications uses C++/CLI wrapper code for the Ogre API. Only the access between the C# application and the Ogre core needs wrapping effort. For Ogre internal work (like rendering) there is no wrapper disturbing. Also I read that C++/CLI should be very fast.
The question could be how much performance the rest of your application needs. Maybe a C++ application environment is faster than a C# one. If the rest of your application needs not much CPU power, then this fact doesn't matter.
If something is wrong with my personal thoughts, be welcome to correct me or tell more details.

Generally it would be interesting to make a performace test between a C++ and C# application using the Ogre kernel. This could be done by a tiny demo application that was ported to C#. Maybe someone did or will do it. To see the fps differents would be nice.


4) Assume I start using Mogre, is there any guarantee MOGRE will exist in the near future (so follow the roadmap of Ogre)?
On open source projects it's not easy to guarantee a long term support.
But think about this: As long as there are users of this project there is an interest to keep it up do date.
On the other hand you could update it yourself. Mogre uses the cpp2java autowrapper and I suppose somewhere in the wiki or forum is an instruction how to do. Even if you have problems with updating - here are some users who have experiences about C++/CLI and would help you. One boy didn't know the wrapping technique, but in the forum I saw that he learned and applied it in just a few days (maybe only a weekend?). Ok, it's important to have C++ knowledge to do this, but you still have it.


5) I saw an article on using Mogre inside WPF (http://www.codeproject.com/KB/WPF/OgreInTheWpf.aspx). Is that important for the Mogre team (do you investigate this? do you recommond this?) Are there other options for communication between Mogre and WPF (not an option to change this, part in WPF is already created)?
An interesting question. I never used WPF, but I saw applications of friends that used WPF (without Ogre/Mogre) and I was impressed. Nice graphic and very fast. So I also want to give it a try when I create a new application.

Unfortunately I can't tell you something about Mogre and WPF. But it would be great if it works well! If not, it would be nice, when somebody tells his experiences and problems. Maybe there are still related forum threads? If so, please tell us!

The answer and question about the performance Ogre vs Mogre I added to the Mogre FAQ in the wiki.
Everybody is welcome to add more useful information there (e.g. about the cpp4java wrapper, WPF etc.)
http://www.ogre3d.org/tikiwiki/tiki-ind ... ogre%20FAQ

6) I already got a working Mogre application, but I can't seem to get the debugging working in VS 2010? Do you have to configure/change something?

If you don't have the need to debug into Mogre/Ogre, just use the release dlls with both configs.

7) I thought DirectX10 and DirectX11 where already supported? Is this correct because the assemblies RenderSystem_Direct3D10.dll and RenderSystem_Direct3D11.dll seem to be missing?

They're not part of the Ogre SDK either. The DX10 rendersystem was on the roadmap for 1.7, but it was delayed to 1.8.

The question is: When you decide to say a software is stable? I suppose after the update to the current Ogre kernel the 1.7 wrapper got the beta status. When several people try it in their applications without problems, then it's fine. When there are problems, we hope they post it here. Mogre will be actively developed / updated. But we need feedback by others. We welcome to give Mogre a try and post your problems when you have some

This is something that has upset me a little bit. I'm not demanding anything, but it's sad to see more than 1.100 downloads of the binaries I provided in just one month and (almost) no feedback at all. Assuming only 1% of these people actually tried it, we should have at least 10-12 post with feedback. But I just counted them again and only needed two fingers to do so.

Nevertheless it's good to see so many people take interest in Mogre, let's just hope that the community will grow fast and feedback and help for Mogre in this forums will increase over time.

2) I checked the assemblies for VS 2010 (target framework 4.0). Some of them (i.e.: Mogre_d.dll, MOIS.dll, MogreFramework.dll) still have the .net framework 2.0 (v2.0.50727) as target framework, is there any reason for this? Will this be updated in the future?

Assuming that you checked with the binaries that I provided for download, I will check this next weekend. At least Mogre_d.dll should target the 4.0 framework.

To be honest, I never cared much about MOIS and MogreFramework. I prefer to use DirectInput through SlimDX and wrote my own framework. That allows me to do some pretty cool things that I could not easily do otherwise. If more people show up who could use MOIS or MogreFramework then I might find some time to update them to the 4.0 framework.

4) Assume I start using Mogre, is there any guarantee MOGRE will exist in the near future (so follow the roadmap of Ogre)?

Like Beauty already said, there is no guarantee that Mogre will be supported forever. And I think the only roadmap we currently have is: when there's a new Ogre version, make it work

I have asked myself this question before when I had to make a decision if I would like to use Mogre or not. After getting to know the inner workings of Mogre pretty well in fixing it for the 4.0 framework and my project, I know I can always fix the things I need to work. All that matters for me right now is: does it get the job done? And that would be a "yes".

Look at it this way: Mogre, like Ogre, is open source software that you can use for free. When you need something fixed, ask people in this great community for help or do it yourself. If you can't afford to do it yourself but need something future proof, maybe a commercial (more expensive) engine with paid support is the better way to go. If nobody will support it anymore in the future then it's up to me to keep it working or I have to find something else I could use.

After I decided to use Mogre, not only for tools but also for my projects, I also decided that I will always make my changes and fixes to Mogre available for everyone here. So there will be new versions available for some time because I can't afford to change everything in my projects to target some other engine in the near future. And, if I remember correctly, the current maintainers of the projects already said that they will be here for some time to create new versions.

The only problem with the version I provide will always be that I, most of the time, only care about those parts of Mogre/Ogre that I actually need for my stuff.

6) I already got a working Mogre application, but I can't seem to get the debugging working in VS 2010? Do you have to configure/change something?

Could you provide some more details about the problems you have debugging?

7) I thought DirectX10 and DirectX11 where already supported? Is this correct because the assemblies RenderSystem_Direct3D10.dll and RenderSystem_Direct3D11.dll seem to be missing?

I did not compile them, because I don't need them at the moment. The code is in my bitbucket repositories and you should be able to compile them. There might be some work necessary to set up the project files configuration first, but I don't see any reason why it should not work. I think that OpenGL would be a better way to use some of the advanced features that newer DirectX version provide, because that would also work on older systems (pre-Vista). But that is just my opinion I'm stuck with DX9 for my projects, because my assets target multiple platforms and using DX10/11 only makes things more difficult.

it's sad to see more than 1.100 downloads of the binaries I provided in just one month and (almost) no feedback at all.
Yes, that's sad, but I'm still impressed about the huge number of downloads!
Maybe there are many new users who got the download link from the Mogre wiki page?
Then they don't know about our feedback whish.
Maybe we should add a note for a feedback which to the places with the download link (first post here and in the forum).

Also I worry about the MogreSDK. I was not active for Ogre/Mogre in the last months. So I don't know about the current state. I hope it will still kept up to date and works well on different systems. I think this is very important to catch and hold new Mogre users. When the first tries with Mogre makes trouble, then quickly the people can ignore this project.
By the way ... mstoyke - are you a new maintainer of Mogre?
Nice to see a new face supporting us

If more people show up who could use MOIS or MogreFramework then I might find some time to update them to the 4.0 framework.
MOIS is a famous way to get user inputs. SlimDX is powerful, but some people could dislike it, because it's not only a library. Is has to be installed additionally and needs bigger setup files. (Maybe important for software published in the internet.)
MogreFramework is only needed for a few tutorial applications.
If it doesn't make much work, it would be nice to recompile them, too.

By the way - is there a disadvantage to use DotNet 4.0 for projects instead of 2.0?

I also decided that I will always make my changes and fixes to Mogre available for everyone here.
Good boy - sharing improvements are great!


The only problem with the version I provide will always be that I, most of the time, only care about those parts of Mogre/Ogre that I actually need for my stuff.
This is also right for other maintainers. Maybe this is also a reason for the beta state. Because on a stable declared project, the people expect that everything works fine.
If something new is not wrapped or updated, maybe the maintainers only want to see that there is an interest. So just ask for unimplemented features - maybe it will be done quickly. (Or try to do it yourself.)

A question:
Where is the current repositroy of Mogre?
Still on sourceforge or on the SVN of user GantZ or somewhere else using Mercurial?

Ok, I added a note for feedback to the wiki page and to the first post.
Also I modified the Mogre wiki page and moved the download link of the MogreSDK 1.4.8 to the SDK history page. It's very outdated and was confusing new users (because it was declared as stable alternative to 1.7.1 beta).

But I'm confused because of the project place.
The MogreSDKs are offered on 2 places:
http://code.google.com/p/mogresdk
http://sourceforge.net/projects/mogre

I suppose sourceforge.net is our main page.
The google page is for the SDK environment (binaries, installer, demos, etc.).
I think it's good when we offer the downloads only at one place.
Maybe we use google only for the SDK development code and offer the installer binaries only at the sourceforge page. It's confusing to have several places. Also it would be more easy to update the downloads only one place.

Additionally there is an SVN on the website of Mogre maintainer GantZ. And I read something about a switch to Mercurial.
What's the current internet infrastructure of Mogre?
I would say, the main page of the Mogre project should be it wiki page. The start pages of sourceforge, google and others should link to this central place. Also there should be a note, that the wiki page is the projects homepage.

I looked again to the wiki page.
It's very important to update these pages:
MOGRE Installation
Mogre Basic Tutorial 0
At least update the current Mogre depencies. They are very outdated (Mogre 1.4.x) and confuse newcomers.
Additionally there could be a note for the MogreSDK installer as alternative.
Currently I don't have the time for much wiki work. So I just add the task here

By the way ... mstoyke - are you a new maintainer of Mogre?

No, sorry, I'm not a maintainer of Mogre and I already said some time ago that I don't have any intentions to become one. I think 10 year ago I would have loved to become a maintainer for something like Mogre/Ogre but these days there are just too much other things that need my time and attention so I can't put enough time into a project like this.

Just look at me as an active supporter of Mogre who is using the wrapper himself and likes to share his changes.

I just like the idea of free open source software but, instead of donating money for using it, I like to "donate" bugfixes and help others in these forums.

By the way, I compiled new binaries of Mogre.dll that should (hopefully) contain a proper fix for the HardwareBuffer Singleton problem.

Mogre 1.7.1 VS2010 / .NET4 binaries HardwareBuffer Singleton Bugfix

My last binary package (that can be downloaded from the sourceforge file repository for mogre) must be installed first and the files in this ^ download should overwrite the old files. If anybody tries it please send me some feedback. I want to create a new binary release for Mogre 1.7.1 / VS2010 / .NET 4 soon but as said before, I don't have much time to test everything.

By the way - is there a disadvantage to use DotNet 4.0 for projects instead of 2.0?

Microsoft did a great job to ensure somebody can still use 2.0 assemblies with 4.0 based applications. But I don't like the idea of mixing different runtimes in one project so I compiled everything targeting the 4.0 framework.

I think the 2.0 binaries have the advantage that you can use them either with 2.0, 3.0, 3.5 or 4.0 applications. The 4.0 binaries can only be used with 4.0 application (as far as I know).

For my projects I stick with the 2.0 framework when I need them to be multi platform (Mono) and run them on a Linux box. But as Mogre will not work with Mono there is no need to stick with 2.0 for the Mogre based projects. So I use 4.0 for all my Windows applications like tools, editors and the game client and 2.0 for the game server and the ASP.Net web pages and web services with Mono and Apache on a Linux box.

Microsoft did a great job to ensure somebody can still use 2.0 assemblies with 4.0 based applications. But I don't like the idea of mixing different runtimes in one project so I compiled everything targeting the 4.0 framework.

Indeed, since 4.0 it's possible that a CLR for 4.0 and one for 2.0 are hosted in the same process, so the dll's can be used.
But like you said, I also don't like the idea of mixing runtimes (even if it works), certainly if it's possible to convert all assemblies to 4.0
So it would be great if also the MOIS was converted ..

A question: are the projects for 4.0 also stored in a repository (svn), or it's just someone who makes those dll's but the work has to be redone for each release of MOGRE?

A question: are the projects for 4.0 also stored in a repository (svn), or it's just someone who makes those dll's but the work has to be redone for each release of MOGRE?

I also stored the solution and project files in my mercurial repositories at
http://bitbucket.org/mstoyke

These repositories have everything needed to compile Ogre and Mogre 1.7.1 with VS2010 and targeting the 4.0 framework...

For both of my repositories there is a named branch "MST", that is the branch I created in each repository to make my changes and build the binaries from.

To compile it, check out the mogre repository first, then check out my ogre repository into Main/OgreSrc into a folder called ogre. Update both checkouts to the latest version of branch "MST" and then compile it. First compile ogre with the LINK_TO_MOGRE define set to 0 in clrconfig.h in ogremain folder, then compile mogre. Now recompile ogre with LINK_TO_MOGRE set to 1 and you should have created all binaries you need.

It should not be necessary to re-create the wrapper files, I also checked in the sources and headers that the wrapper generator creates.

If you have any problems compiling, just wait for my detailed step by step instructions. I hope to find some time soon to write down some more detailed information in the wiki. If you have any problems compiling, leave me a note so I can fix it or at least write the solution to the encountered problems in my build instructions.

I'm getting the same singleton issue with Ogreroot that was described before with a Windows 64bit machine. Did anyone every find out the solution to this problem? I have Mogre 1.6.5 working on the machine, and I've installed the latest version of DirectX. Was Mogre built for the X86 platform?

Scott

I also stored the solution and project files in my mercurial repositories at
http://bitbucket.org/mstoyke
I think it would be a good idea to maintain your files in the Mogre repository.
Ask GantZ for access.

Additionally: Even if you aren't a maintainer it would be good when you are a full access admin for the Mogre repository(ies), because GantZ will leave this project soon and it's good to have an active person with full access. When somebody wants to carry on the maintain work, he needs somebody who gives him admin rights. So you would be a useful contact person.

I just tried to compile Mogre on my own and everything went smoothly (more or less) but I'm missing the sources for "MogreFramework" (which I still need). They don't seem to be included in the Mercurial repository. Any idea of where I can find them?

The MogreFramework is only needed for some tutorials (if I remember right).
You find it in the SVN of the MogreSDK, including source code. (I don't know if it's included to the setup file.)

Here is the SVN browser access:
http://code.google.com/p/mogresdk/sourc ... eFramework
Or check out the full MogreSDK
http://code.google.com/p/mogresdk/source/checkout
and go to path smiley80\mogre_basic_tutorials\MogreFramework.

I suppose this is the right file you need.

@smiley80: Is it right? (or is this a different file with the same name like the very old MogreFramework.dll?)


How does it comes that the autowrapping process needs the MogreFramework?
Is it just for an easy update of the SDK binaries?


I never build Mogre and don't know how to use the autowrapper. But it's nice to see that a newcomer could do it without problems
@manski: Did you use the guide of wiki page Building MOGRE 1.6 from source? If yes, were there much differences?
Great would be if you can update the wiki for building Mogre 1.7. (For this please clone the 1.6 page - see my notes at top of the 1.6 building page)

Additionally: You are a Mogre newcomer - welcome!
If you try out some basic tutorials (in the wiki) and have problems (e.g. because of outdated issues), then please post the bugs in our forum. Or just add a note to the related part of the wiki. (you can log in to the wiki with the user name/password of the Ogre main forum)
This makes it more easy to update the wiki pages.

The MogreFramework is only needed for some tutorials (if I remember right).
You find it in the SVN of the MogreSDK, including source code. (I don't know if it's included to the setup file.)

Ah - now I get it. There is a difference between "Mogre" and the "Mogre SDK" (very confusing that these seem to be different projects).

How does it comes that the autowrapping process needs the MogreFramework?

It doesn't. I just needed the HardwareBufferManager which I read didn't work in the official 1.7.1 beta SDK release so I figured that it's time for me to compile Mogre myself and try to find and apply a patch for this problem.

I never build Mogre and don't know how to use the autowrapper. But it's nice to see that a newcomer could do it without problems
@manski: Did you use the guide of wiki page Building MOGRE 1.6 from source? If yes, were there much differences?
Great would be if you can update the wiki for building Mogre 1.7. (For this please clone the 1.6 page - see my notes at top of the 1.6 building page)

Yes, I will update the wiki.

(you can log in to the wiki with the user name/password of the Ogre main forum)

It took me a while to figure this one out as there's no registration link on the wiki and no mention that the forum account will work (at least I found nothing of the like).

Note:
I moved 2 posts about Mogre maintaining to the thread Seeking for a new maintainer.

Some simple instructions how to build Mogre/Ogre 1.7.1 for VS2010/.NET4 from my repositories can be found here:
http://www.ogre3d.org/tikiwiki/Building+MOGRE+1.7+from+source
I will write a more detailed manual later that will also cover topics like Ogre patching and wrapping the API.

@smiley80: Is it right? (or is this a different file with the same name like the very old MogreFramework.dll?)
Yes, it's the MogreFramework required for the basic tutorials.

Some simple instructions how to build Mogre/Ogre 1.7.1 for VS2010/.NET4 from my repositories can be found here:
http://www.ogre3d.org/tikiwiki/Building+MOGRE+1.7+from+source
I will write a more detailed manual later that will also cover topics like Ogre patching and wrapping the API.

Good work!
I put it to the "wiki structure" (similar to a cathegory), added links and made some tiny changes.

I updated the SDK installer to the latest SVN revision 72. Can someone please update the installer at sourceforge? I have no sufficient rights to do this.

I updated the SDK installer to the latest SVN revision 72. Can someone please update the installer at sourceforge? I have no sufficient rights to do this.

I've uploaded the new installer on sourceforge.

I just stumbled over a very nice AccessViolationException in Mogre 1.7.1. It's reproducable. It always happens when you keep a pointer returned from one of Mogre resource managers. It seems that Ogre (or Mogre) deletes the pointer before the CLR object gets removed by the garbage collector.

To reproduce this error use the initial code from this tutorial and modify the SceneCreator class like this:


class SceneCreator
{
private MeshPtr m_mesh;
private TexturePtr m_texture;
private MaterialPtr m_material;

public SceneCreator(OgreWindow win)
{
win.SceneCreating += new OgreWindow.SceneEventHandler(SceneCreating);
}

void SceneCreating(OgreWindow win)
{
// Use any of these line to reproduce the exception. Uses stuff from the MogreSDK.
this.m_mesh = MeshManager.Singleton.Load("ninja.mesh", ResourceGroupManager.DEFAULT_RESOURCE_GROUP_NAME);
//this.m_texture = TextureManager.Singleton.Load("GreenSkin.jpg", ResourceGroupManager.DEFAULT_RESOURCE_GROUP_NAME);
//this.m_material = MaterialManager.Singleton.Load("Ogre/Skin", ResourceGroupManager.DEFAULT_RESOURCE_GROUP_NAME);
}
}


Maybe this is just bad pratice but I think this should be fixed. The beauty about a garbage collected language is that you don't need to worry about dangling pointers and so Mogre should make sure that it doesn't "break" this concept.

Update: Just to clarify this. The exception happens when you close the Mogre application.
Update 2: Removed entity as it doesn't seem to exibit the problem.

Maybe this is just bad pratice but I think this should be fixed.
Always call Dispose on types that implement IDisposable. Always, always on types that wrap a native type which inherits from Ogre::SharedPtr<T>.

Always call Dispose on types that implement IDisposable. Always, always on types that wrap a native type which inherits from Ogre::SharedPtr<T>.

Not sure how this relates to my problem. And even if it does, this should not result in AccessViolationExceptions.

The problem is that you have a MeshPtr instance and there is no guaranteed order of destruction when you close your app. So what ends up happening is that Mogre shuts down and in turn Ogre gets destroyed. You've still got the MeshPtr so when it finally gets its turn on the finalizer queue, it goes to destroy itself and it cannot do that anymore because Ogre has already destroyed the object.

I have been boned by this quite a bit and it's a hard issue to track down in a large application. You eventually get used to it and start keeping diligent tabs on things but I would like to open up discussion about some possible fixes for it. Or at least an option to compile in a 'safe checking' version of it somehow.

I haven't thought about this much but it could introduce a huge perf hit if we check whether a pointer to the native struct is valid every time you access it. This isn't strictly related to objects being garbage collected as you can also run in to it when you destroy something manually, other pointers to it are invalid. It's the same thing in C++ as having two pointers to an object and deleting one. The second one is invalid and it's usually the clients responsibility to monitor this.

Any thoughts about even a possible compilation option that we could use to safe guard against this?

Shawn

The problem is that you have a MeshPtr instance and there is no guaranteed order of destruction when you close your app. So what ends up happening is that Mogre shuts down and in turn Ogre gets destroyed. You've still got the MeshPtr so when it finally gets its turn on the finalizer queue, it goes to destroy itself and it cannot do that anymore because Ogre has already destroyed the object.

That's what I thought.

I haven't thought about this much but it could introduce a huge perf hit if we check whether a pointer to the native struct is valid every time you access it.

I think the best way would be to set a "MeshPtr" to "NULL" if its native pointer gets deleted (not sure tough whether this can be done without large amounts of code). So there would be a (possible) performance hit when deleting an object. Checking whether the pointer is "NULL" in this case shouldn't be much of an performance hit as C# (CLR, Java, ...) does this check on "every" call regarding reference types (i.e. objects) anyway. (Otherwise it could not detect "NullPointerExceptions".)

This isn't strictly related to objects being garbage collected as you can also run in to it when you destroy something manually, other pointers to it are invalid. It's the same thing in C++ as having two pointers to an object and deleting one. The second one is invalid and it's usually the clients responsibility to monitor this.

That's called a "dangling pointer". However, in my opinion (and I'm sure I'm not alone with this) "dangling pointers" must not occur when programming C# (or any other garbage collected language such as Java). It's the whole point of having a garbage collector that it ensure that you can't delete pointers still used elsewhere.

Any thoughts about even a possible compilation option that we could use to safe guard against this?

Why do you want a compile option for this? I doubt compile options are a good solution as the Mogre team would need to provide binaries for every compile option combination - which could get a lot if there were some (read: more than two) compile options.

Maybe this is just bad pratice but I think this should be fixed.
Always call Dispose on types that implement IDisposable. Always, always on types that wrap a native type which inherits from Ogre::SharedPtr<T>.

Do I have to call Dispose on an Entity after SceneManager.DestroyEntity() ?

I just stumbled over a very nice AccessViolationException in Mogre 1.7.1. It's reproducable. It always happens when you keep a pointer returned from one of Mogre resource managers. It seems that Ogre (or Mogre) deletes the pointer before the CLR object gets removed by the garbage collector.

I've analyzed the problem (sort of). Here are my findings: This problem arises if there are still shared pointer instances (like "MeshPtr", "TexturePtr", or "MaterialPtr") that weren't disposed before calling "Mogre.Root.Dispose()" (and that weren't disposed manually after disposing the root). If you call "Dispose()" on every shared pointer instance you have before (or even after) disposing the Ogre root than there is no problem. The problem only arises when the garbage collector tries to collect a shared pointer instance after the root has been disposed.

Although disposing the pointers before disposing the Ogre root solves the symptoms, I didn't quite understand why there even were "AccessViolationExceptions". So I investigated this further. I used the code from my previous post and used a "TexturePtr". Here's the code again. I modified and trimmed it a little bit to only contain the necessary information. I also added a method to explicitly dispose the Ogre root (which is called when the main window gets destroyed).


class MyOgreWindow : MogreFramework.OgreWindow
{
  private TexturePtr mTexture;

  protected override void OnSceneCreating()
  {
    this.mTexture = TextureManager.Singleton.Load("GreenSkin.jpg", ResourceGroupManager.DEFAULT_RESOURCE_GROUP_NAME);
  }

  private void OgreWindow_Disposed(object sender, EventArgs e) 
  {
    base.mRoot.Dispose();
    base.mRoot = null;
  }
}


I tried the following four different solutions of which only the last one failed.

Dispose texture before root (works):

private void OgreWindow_Disposed(object sender, EventArgs e)
{
this.mTexture.Dispose();
base.mRoot.Dispose();
base.mRoot = null;
}


Dispose texture after root (works):

private void OgreWindow_Disposed(object sender, EventArgs e)
{
base.mRoot.Dispose();
base.mRoot = null;
this.mTexture.Dispose();
}


Garbage collector texture before disposing root (works):

private void OgreWindow_Disposed(object sender, EventArgs e)
{
this.mTexture = null;
GC.Collect();
base.mRoot.Dispose();
}


Garbage collector texture after disposing root (fails):

private void OgreWindow_Disposed(object sender, EventArgs e)
{
base.mRoot.Dispose();
this.mTexture = null;
GC.Collect();
}


Strangly in the last version "GC.Collect()" doesn't seem to collect the texture pointer whereas it does in the third version (when running the GC before disposing the root). I also tried calling "GC.Collect()" multiple times with no effect. So the last version seems to be equivalent to not clearing the texture pointer manually at all (but leaving this job to the garbage collector). And then this fails when closing the application as Windows seems to delete the native texture pointer (Ogre.TexturePtr) before the garbage collector collects the managed texture pointer (Mogre.TexturePtr) and thereby crashing the whole thing. This is propably the reason why the following comment can be found in "OgreSharedPtr.h:225":


// IF YOU GET A CRASH HERE, YOU FORGOT TO FREE UP POINTERS
// BEFORE SHUTTING OGRE DOWN
// Use setNull() before shutdown or make sure your pointer goes
// out of scope before OGRE shuts down to avoid this.


Not sure whether I've any more question other than: Does anyone know why in my last code version the garbage collector doesn't run?

PS: Sorry for the post being so long.

Just found out how I can "fix" my last code version:


private void OgreWindow_Disposed(object sender, EventArgs e)
{
base.mRoot.Dispose();
base.mRoot = null;

this.m_texture = null;
GC.Collect();
GC.WaitForPendingFinalizers(); // AccessViolationException is thrown in this call
GC.Collect(); // therefore this line isn't reached
}


However, this will result in the same AccessViolationException as my last code version - only sooner. What I don't understand is: why?

This code should be identical to my second code version from above (disposing the texture pointer after dosping the root) except that the "Dispose()" method is called from the finalizer thread in this case. So in theory it should not throw this exception. Any ideas?

This code should be identical to my second code version from above (disposing the texture pointer after dosping the root) except that the "Dispose()" method is called from the finalizer thread in this case. So in theory it should not throw this exception. Any ideas?
The second version causes an AccessViolationException for me.


Do I have to call Dispose on an Entity after SceneManager.DestroyEntity() ?
I don't think so. Entity.Dispose doesn't try to delete the native object, because the '_createdByCLR' field seems to be always false.

In my experience, the critical Mogre types are ResourcePtr and derived. You should explicitly dispose every instance:
using (ResourcePtr res = TextureManager.Singleton.GetByName(textureName))
{
using (TexturePtr texture = res)
{
}
}

Hi

Many thanks for the work on Mogre!

Installed latest Mogre SDK 1.7.1 from Mogre Wiki download link to Windows 7 64 / Visual Studio 2010. SDK tool passed on dependency check and build. The samples did not run after that. Visual Studio 2010 build passed after converting the solution. Again the samples did not run due to some dependencies being 32 bit dlls and default build configuration used ANY CPU. After changing to x86 CPU and building the samples are running well. Could be good to select explicitly x86 CPU in the included Visual Studio project files if the included dlls are 32 bit versions.

Regards,
Tommi

Thanks smiley80. That's a very important information.
I will have to check my code. As I remember I left this ResourcePtr for GC to handle. Strange it do not crashes.

As I remember I left this ResourcePtr for GC to handle. Strange it do not crashes.

Like I said: If the GC removes the object before Ogre is shutdown, then there is no problem.

No, you might get InvalidCastExceptions randomly if you let the GC finalize a ResourcePtr.

Some people are currently experiencing problems using Mogre addons (FreeSL, Hydrax, MogreNewt, ...) with Mogre 1.7.1. It is the next priority to get all these addons working with Mogre 1.7.1, but it's a lot of work and will take some time. Anybody who is interested in maintaining one or more addons for Mogre should just send me a PM and I can give you write access to the new mercurial repositories at bitbucket.

I've already said before that I can take care of the Mogre wrapper, but the responsibilities for all Mogre project need to be split up between more maintainers.

The current list of maintainers is as follows:

- Mogre technical maintainer -> mstoyke
- Mogre documentation maintainer -> Beauty
- Mogre SDK maintainer -> kwertz
- Mogre addons maintainer -> (?)

As you can see, nobody is really responsible for the addons so far and I will only find time to update one or two of the current addons to Mogre 1.7.1 in the near future. So anybody who would like to help the Mogre project should PM me (or any of the other maintainers).

Currently we have the following projects in the Mogre addons bitbucket repository:
- HikariWrapper
- MOIS
- MQuickGUI
- MogreDesignSupport
- MogreFreeSL
- MogreNewt
- PLSM2Helper

I will soon update MOIS and MogreFreeSL, because these are the two addons I'm currently using myself.

I'm using MogreNewt and MogreFreeSL in my project.

As far as my project MogreNewt is stable.
For now I have disabled MogreFreeSL since there were some changes in mogre 1.7 with scenenode no longer being Renderable class.

No, you might get InvalidCastExceptions randomly if you let the GC finalize a ResourcePtr.

Really? I don't see how this could happen (when I look at the source code of "Mogre.TexturePtr" that is; maybe its different for other types?). The only mention of "InvalidCastException" (again in "Mogre.TexturePtr") is when you assign a "ResourcePtr" to a "TexturePtr" for which an automatic conversion is implemented. Do you have a (partial) stack trace? I ask because I'm currently working on a solution to prevent the "AccessViolationExceptions" from happening (since I really like to have a rock solid stable MOGRE version - at least for myself).

I've never got the exceptions on my machine, but they were reported for Miyagi by several people.
They happened (randomly) in op_Implicit(ResourcePtr) of TexturePtr or FontPtr (guess it also applies to the other *Ptr types).
The solution was to dispose both the underlying ResourcePtr and the conversion result.

dependencycheck.exe fails on Visual C++ 2008 Runtime. I've installed the runtime twice and restarted my computer as well. I have VS2010 installed. Could this interfere? Please help me get this setup. I am supposed to be researching this engine and come up with recommendations for my team. Thanks.

dependencycheck.exe fails on Visual C++ 2008 Runtime. I've installed the runtime twice and restarted my computer as well. I have VS2010 installed. Could this interfere? Please help me get this setup. I am supposed to be researching this engine and come up with recommendations for my team. Thanks.

Are you planning to use an older framework (2.0, 3.0 or 3.5) with VS2010 or do you want to target .NET framework 4.0? In the latter case you can't use the Mogre version from the SDK installer and should use the binaries that you can find here.

If in doubt, just try to create an application that just initializes Mogre and check if you can start the executable without any errors. I'm not sure how dependenycheck works exactly, but I hope our SDK maintainer kwertz can help you here...

I think, if you use VS2010, you should also use the VC++ 2010 redistributable. I have not tried to run the VS2008 compiled libraries with a VS2010 compiled project yet, but I'm planning to do so soon. Currently we recommend VS2008 if you target any framework prior to 4.0.