Some x64/x86 builds of Mogre 1.7.3 ("Cygon Builds")

Hi!

Over the weekend, I've done some builds of Mogre with Ogre 1.7.3 targeting x64. I also decided to build all dependencies from scratch to achieve a homogenous build, so I'm now using Boost 1.47.0, FreeImage 3.15.1 and CG 3.0.

Everything seems to be working fine, except for one thing: when I load Ogre's OpenGL driver, I get a crash during shutdown in Boost -> run_thread_exit_callbacks() (thread.cpp).

This happens with the x86 build and the x64 build equally (same behavior, same reproduction, same crash site), so I don't think it's an x64-specific problem. On the other hand, I think vanilla Mogre uses statically linked Boost libraries, whereas I use a hand-compiled DLL version (containing only Boost.Thread, Boost.Date_Time and Boost.Regex).

Basically, I just wanted to ask -- has anyone here ever attempted using Boost in a DLL? Did it work?

EDIT: The issue has since been tracked down, it's because Mogre.Root.Shutdown() is being called by .NET's GC thread and Ogre's OpenGL RenderSystem can't handle a shutdown from a different thread currently. Currentl build works around this by moving the shutdown code into the finalizer instead of the destructor. This means you leave resource cleanup to the OS if you don't call Root.Shutdown() when your game terminates. The workaround hopefully won't be necessary for future Ogre releases.

If anyone wants to give it a try:
http://www.nuclex.org/MogreTutorial-1.7.3-VC2010-x86-x64.7z (~55 MiB)
http://www.nuclex.org/MogrePatchesAndSolutions-1.7.3.7z (~140 KiB)
Sorry about the file size, I included the .pdbs of everything so that crashes can be tracked down. Extracted size is about 623 MiB.


NOTES FROM FURTHER POSTS:
-----------------------------------------

You need to copy the dll files from:
.\References\ogre\msvc-10.0-x86\
.\References\mogre\net-4.0-x86\
.\References\freeimage\msvc-10.0-x86\
.\References\tr1boost\msvc-10.0-x86\
.\References\cg\msvc-10.0-x86\ (for Cg)
.\References\mois\net-4.0-x86\ (for Mois)
.\References\ois\msvc-10.0-x86\ (for Mois)
(or 'x64' if you want to use the 64-bit version)

The easiest way to use this Mogre build in a new project would be to just take the "References" and "MogreDependencies" from the example, then add a reference to Mogre.dll and to the MogreDependencies project.

Sidenote: some people just dump such DLLs into the bin\Debug or bin\Release directories by hand, but since the 'bin' directory typically isn't committed to a VCS and everyone downloading a working copy would have to do additional steps then, it's better to add those DLLs as files to the project and use the "Copy to Output Directory" feature. This is what the "MogreDependencies" project in my example does. I used a separate project so I don't clutter up the main project.



The exact dependencies are:

1. DirectX June 2010 (I compiled Ogre against the June 2010 DirectX SDK)[/*:m]
   
2. Visual C++ 2010 SP1 runtime (every single binary in this build is compiled with that compiler and uses the DLL runtime)[/*:m]
   
3. An SSE2-capable CPU (I enabled it in all projects since it improves performance and I think all Pentium IIIs and Athlon XPs have been phased out by now)[/*:m][/list:u]
   

Do I not need anymore Debug or Release versions of the Mogre and Ogre dlls? The same for both configurations?
Use the same for both configurations. [...]




What do I need the "tr1boost.dll" in my execution directory for
It contains the backing code of Boost (date_time, regexp and math). Vanilla Ogre links to Boost as a static library, but then you end up with one additional copy of the Boost code in memory for each Ogre DLL, which I considered wasteful, so I compiled the required parts as a DLL. The "Tr1Boost" name is because it's a minimal subset of Boost, containing only the headers required by Ogre and to support C++ TR1 in Visual C++ 2010 SP1. Only 902 headers instead of 8597 for Boost 1.47


Cygons x64 build is extremely stable under multithreading.

I tried statically linking Ogre and Mogre, but using the OpenGL renderer still causes a crash on shutdown. Maybe my build configuration is no good or maybe this is one issue where Mogre doesn't work with 1.7.3 yet.

One other thing I noticed was that these AutoWrap-generated headers include all Ogre headers in C++/CLI managed mode (meaning the compiler will generate MSIL for lots of internal structures and C++ standard library classes). As an experiment, I hand-edited the autogenerated headers (yeah, I should really have modified AutoWrap instead) like this:

#pragma managed(push, off)
#include "OgreRoot.h"
#pragma managed(pop)
#include "MogreFrameListener.h"

To make sure the CLI code in CLRObject.h and CLRHandle.h still worked, I temporarily re-enabled CLI with

#if defined( __cplusplus_cli )
#pragma managed(push, on)
#endif
...
#if defined( __cplusplus_cli )
#pragma managed(pop)
#endif

at the appropriate places.

As a result, my Mogre.dll shrunk from 12.3 MiB to 8.0 MiB for the x86 build and from 20.8 MiB to 9.0 MiB for the x64 build. A quick look in ILspy reveals that there is still a lot of potential for savings left:



I also successfully attempted an x64 build of OIS and MOIS, enabling me to use the TutorialFramework. The package on my website I linked to in the previous post has been updated with the new, smaller binaries and MOIS. The statically linked Boost built got thrown out again, no need to keep 4 copies of it in memory if it doesn't improve the situation with the OpenGL renderer.

The version information does not seem right.

I downloaded your directory and tried it. As I have a 64bit operating system I tried only this solution.

Result:
I could build it successfully and it ran but there were some problems.

Problems:

1. I got an error because "cg.dll was not found on your computer". Disabling the cg plugin solved that problem.[/*:m]
   
2. Using Direct3D9 everything worked fine.[/*:m]
   
3. I modified the plugins.cfg file to use the OpenGl plugin. It worked fine but when I closed the application there was an error "MemoryAccessViolation".[/*:m]
   
4. Input worked for both versions.[/*:m][/list:u]
   I will test it a liitle bit more and compare the results with the existing TutorialFramework.
   
   Definitely good work fro the whole community! If you need some help please let me know!

Thanks!

@umityildiz: I wondered what's up with the Version 0.0.0.0 myself already, I'll check if AssemblyInfo.cpp being correctly linked into Mogre.
@McDonte: I forgot to add CG.dll to the x64 build of my MogreDependencies project (x86 was fine). I'll fix it the next time I update my package.

Regarding the OpenGL shutdown crash:

This seems to be related to Ogre's use of threads. Some OpenGL resources are freed in a different thread than the one they were created in. Each thread accessing OpenGL in Ogre is assigned a new 'glew' context (some OpenGL extension library), including the shutdown thread, which thus tries to create a new 'glew' context during shutdown. That is what causes the crash, though I'm not sure why exactly the 'glew' context creation crashes so hard.

This is what I observed:

1. Startup creates an OpenGL context in 3 threads:
   glewGetContext() from Thread 4664
glewGetContext() from Thread 5176
glewGetContext() from Thread 5084[/*]
   
2. Rendering loop runs (and works fine)[/*]
   
3. Shutdown requests OpenGL context from new thread:
   GLSLProgram::unloadHighLevelImpl() from Thread 4832
-> glDeleteObjectARB()
-> glewGetContext()
-> glewInit()
-> Access Violation reading location 0x0000044c[/*]
   [/list:o]
   
   It's not unlike what this Ogre user reported: Problem (crash) when removing resources on shutdown. I'll go ask in the Ogre forums as this doesn't seem to be a wrapper error per se and I've got about zero experience with OpenGL.

So, just did my little cross-post: Crash during Shutdown of OpenGL Renderer.

I hope someone in the Ogre forums knows something that helps me track down the issue.

Also got an AccessViolationException on shutdown with the OpenGL renderer. This was due to two undisposed local Hardware*BufferPtrs. Disposing them fixed the issue.

GLSLProgram::unloadHighLevelImpl
looks like it might get called from a MaterialPtr destructor. Do you have any MaterialPtr (fields or locals) you don't dispose?

I'm just running the Mogre TutorialFramework code -- I was hoping that this shows the proper usage of Mogre

Anyway, I figured out what was going on: Mogre implemented a finalizer for the 'Root' class. This finalizer is invoked in the .NET Garbage Collector thread, thus launching the resource cleanup from a totally new thread. Apparently the OpenGL driver doesn't like that (and the other thread I linked to seems to confirm that Root::Shutdown() is supposed to be called in the same thread that called Root::Initialize()).

I changed the behavior so that a Root::Shutdown() is no longer attempted from the GC thread. As a consequence, you should make sure to call Root::Shutdown() when your application terminates or the resource cleanup will be left to the OS (just like it is for C++ developers using Ogre). A nicer solution would be to allow Root::Shutdown() to be called from any thread, but short of creating a message window for thread synchronization in Root::Initialize(), this would mean a lot of changes (and running the message pump inside the garbage collector), so I opted for the obvious fix.

Of course doing proper cleanup is always the better choice, but at least Mogre won't come up with an ugly access violation if you're being lazy.

The package on my website has just been updated once more, here are the changes:

1. Fixed OpenGL shutdown crash[/*:m]
   
2. Added missing CG.dll for x86 test project[/*:m]
   
3. Assembly version of Mogre.dll is now correctly set[/*:m]
   
4. All managed assemblies are now signed with a strong name (allows them to be used in projects that use signed assemblies and to install Mogre in the GAC, potentially enabling AnyCPU projects to automatically load the approriate x86/x64 binaries)[/*:m]
   
5. Included all patched Ogre headers, so you could use this package like an Ogre SDK[/*:m]
   
6. Included all Mogre headers, same motivation, allows you to compile 3rd party packages against the SDK[/*:m]
   
7. Added Newton 2.33 binaries (both x86 and x64 builds)[/*:m]
   
8. Updated MogreNewt to work with Newton 2.33, also fixed a minor bug in the wrapper[/*:m]
   
9. Added BulletSharp 0.15 updated to compile with Bullet 2.78 (also x86 and x64 builds)[/*:m][/list:u]
   
   I haven't verified Newton and Bullet in depth yet, but some basic tests came out okay.
   
   All that's left to do now is to clean up my workspaces and create some clean patches with my changes.
   Depending on the effort required, I plan to see if I can get MogrePlant and MogreFreeSL compiled, too, then I'll call it a day

Great work !!
I'm happy to see that you could manage the problems and published a fresh Mogre package.

* Added Newton 2.33 binaries (both x86 and x64 builds)
* Updated MogreNewt to work with Newton 2.33, also fixed a minor bug in the wrapper
For my main application I still use Mogre 1.6, because for 1.7 I had trouble in combination with the MogreNewt wrapper (built for 1.7). Next week I will test it with your binaries again. Perhaps now my collision detection works with 1.7.
This would be fine for me, because with Mogre 1.7 I could use improvements of Ogre and all the debugging possibilities of the extended MogreNewt wrapper.
In the case that the MogreNewt problems (related to Mogre 1.7) are solved, I also could update my collision detection demo application.
I will post an announcement in the "official" MogreNewt topic. So the people with its suscription will know the good news and are invated to test your new build.

I changed the behavior so that a Root::Shutdown() is no longer attempted from the GC thread. As a consequence, you should make sure to call Root::Shutdown() when your application terminates
I wonder how it was done in the past. Why we didn't have this problem in the past? Perhaps some internals of OpenGL did change?
Smiley80 also published an Mogre build, based on Ogre 1.7.3. He didn't have such a problem. (At least I didn't read about this.)

To call Root::Shutdown() is an easy step. But everybody who doesn't know could get trouble. (e.g. just replace the binaries or use older source code from the wiki/forum).
What happens if somebody doesn't call Root::Shutdown()? Will there be an exception?
Perhaps you/we should add an entry to the Ogre logfile. For example: IMPORTANT: Since Mogre 1.7.3 you need to call Root::Shutdown() before terminating your application.

I'm just running the Mogre TutorialFramework code -- I was hoping that this shows the proper usage of Mogre
Yes, the framework shows the basic usage of Mogre.
I know that there are a few basic demos in the Mogre repository. The old maintainers used them to make a quick check of new builds. I can't tell you more details (because I never build Mogre), but perhaps for you it's useful to know about their existence.

The package on my website has just been updated once more
I suppose it's still the same URL:
http://www.nuclex.org/MogreTutorial-1.7.3-VC2010-x86-x64.7z (~47 MiB)

All managed assemblies are now signed with a strong name (allows them to be used in projects that use signed assemblies and to install Mogre in the GAC, potentially enabling AnyCPU projects to automatically load the approriate x86/x64 binaries)

Did you see any performance difference between the x86 and x64 build?
The senior developer mstoyke said, that he never saw a difference for 3D applications.

Now there is an "automatic switch" for x86/x64.
Is it now required to include both binary versions to Mogre applications?



Depending on the effort required, I plan to see if I can get MogrePlant and MogreFreeSL compiled, too
If you are looking for new tasks - perhaps have a look to the sweet water simulation add-on "Hydrax".
There exists a Hydrax wrapper for Mogre, but the author retired and other people couldn't manage to update it to work with Mogre 1.7.
Videos, screenshots, downloads (e.g. a demo) and further links you find on the wiki page Managed Hydrax Wrapper.
It's forum topic is here (including discussion of the update problems).

Because of the update problems I asked the retired author for an update. He could update most parts, but one problem he couldn't solve problem.
Details he wrote here (including plain source code):
viewtopic.php?p=78404#p78404
His whole project (including binaries, etc.) I uploaded to the SVN:
viewtopic.php?p=78420#p78420

... oh, wait ... I scrolled through the whole forum topic again. Perhaps the problems are solved now?
I'm not shure. If you are interested in sweet water, just try it.

To call Root::Shutdown() is an easy step. But everybody who doesn't know could get trouble. (e.g. just replace the binaries or use older source code from the wiki/forum). What happens if somebody doesn't call Root::Shutdown()? Will there be an exception?

Not calling Root::Shutdown() does, well, nothing - e.g. no exceptions, no trouble, except that you leave resource cleanup to the operating system.
I have no idea why the other 1.7.3 binaries don't have the issue. I'll check them out, the relevant bits of code are in the managed parts, luckily, so I can even look if there's something different via ILspy.

There has been a lengthy discussion about some threading issues in the OpenGL driver here:
OpenGL renderer crashes in Multi-document app

The OpenGL driver might need a little bit of work (eg. not initializing glew for any new thread encountered and checking if a GL context exists before initializing glew) to fully support the more exotic multithreading cases - like being shut down in a different thread. Maybe I should raise the issue in my Ogre forum thread?

Did you see any performance difference between the x86 and x64 build?
The senior developer mstoyke said, that he never saw a difference for 3D applications.

I don't have any meaningful scene to test with and benchmarking a nearly-idle render loop is probably a bit silly, but here are the numbers:

1. x64 D3D: 3030 fps[/*:m]
   
2. x64 OGL: 1170 fps[/*:m]
   
3. x86 D3D: 2930 fps[/*:m]
   
4. x86 OGL: 1160 fps[/*:m][/list:u]
   
   Now there is an "automatic switch" for x86/x64.
   Is it now required to include both binary versions to Mogre applications?
   
   Nah, I merely signed the assemblies. Everything stays as it was, you can ship an x86-only or an x64-only release as before.
   
   To get .NET to automatically select the x86 or x64 version of the assemblies, you'd have to compile your main executable as 'AnyCPU', keep Mogre strictly in the GAC and find a solution for the native binaries (requires some guru skills with embedded manifests, I believe).

Maybe I should raise the issue in my Ogre forum thread?
In this case the Ogre maintainers are remembered that there is a gap and somebody is interested in a solution.
If nobody shows an interest in something, there is a lesser chance to get something solved.

I don't have any meaningful scene to test with
I can send you a few mesh models whith a huge amount of polygons.
They doesn't contain textures, but the benchmark results should be better than idle loops.



Cygon, you seem to be a well known programmer.
If you like, I can give you write access to the Mogre repository.
Just give me your e-mail address.

Our latest Mogre maintainer (mstoyke) wrote some suggestions/rules how to handle commits.
He wants to prevent Mogre becomes instable. (Please only commit changes if you are shure that the changes are not experimental. For experimental builds, use an other repository.)
And he wants to keep the repository small. (Don't commit useless stuff like temporary files, huge resources, etc.)
Well, mstoyke is idling for a few months. So I skip his rule, that official commits need an agreement by him.
I don't want that Mogre has a deadlock.

I can send you a few mesh models whith a huge amount of polygons.
They doesn't contain textures, but the benchmark results should be better than idle loops.

Increasing the raw poly count is not an issue, I can just set up an Ogre head cloning factory here

With 32 heads (128 meshes/draw calls and 71,744 vertices):
x64 OGL: 540 fps
x64 D3D: 1580 fps
x86 OGL: 390 fps
x86 D3D: 1430 fps

With 2000 heads (8000 meshes/draw calls and 4,484,000 vertices):
x64 OGL: 23.0 fps
x64 D3D: 36.7 fps
x86 OGL: 21.4 fps
x86 D3D: 36.7 fps

I don't know Ogre and Mogre well enough to say if there are any features that would result in large numbers of managed/unmanaged transitions and if these would have a different impact, but pure rendering performance of Ogre in 64 bits seems to be the same as it is in the x86 version.

Cygon, you seem to be a well known programmer.
If you like, I can give you write access to the Mogre repository.
Just give me your e-mail address.

I don't want to take this too far. My only goal for the time being is to get some working, up-to-date Mogre builds in order to evaluate whether I'll stay with XNA+SunBurn, switch to Mogre or maybe check out some other options. Updating and Ironing out Mogre, should it require that, is not what I want to do - I'm looking to have some fun and create a game in what little free time I have!

rendering performance of Ogre in 64 bits seems to be the same as it is in the x86 version.
x64 seems to be a little bit faster.
The most conspicuous thing is the difference between DirectX and OpenGL.
Perhaps it's related to some internal OpenGL changes which were added to Windows Vista (and Win 7).

I don't want to take this too far. [...] Updating and Ironing out Mogre [...] is not what I want to do
I don't want to steal your free time.
I just thought: Hey, Cygon already did some improvements to Mogre. Perhaps some more in the future. So it would be a benifit to all Mogre users, when these improvements are included to the official repository.
Ironing our and heavy tests would be fine in general, but a "simple tested" fresh Mogre would be better than an outdated version.

maybe check out some other options
Perhaps the Axiom project is interesting to you. It's a C# port of Ogre. Not all, but many new features of Ogre are still included. (This I heard, although I never tried it.)
Also the Alimer Engine based on Ogre could be interesting. It offers 2 engine types. One is a P/Invoke wrapper for Ogre (also usable by Mono/Linux/MacOS) and the other type for XNA usage. (So you could use the whole XNA content pipeline.) Unfortunately the website is down, but much information is in the forum topic. If you want to give it a try, just ask user boyamer - He's the lead developer.

evaluate whether I'll stay with XNA+SunBurn, switch to Mogre or maybe check out some other options.
Never mind how you will decide. Use the option which is most comfortable to you.
When your checks are done, we would be happy if you publish a small comparison. (What are good and bad points for Mogre, XNA and other options?)

Could you put the date and version number next to the download link? Also Is there a possibility to publish frequently updated?

Cygon, if you are interested in the new terrain component (with possibility to edit terrain), have a look to a fresh post of the topic In Development: Mogre Terrain and Paging. In his next post he isn't shure about the source code usage. Perhaps you have a suggestion?

As I read that you also offer x86 builds, I changed the topic title to:
Some x64/x86 builds of Mogre 1.7.3.

Just a note on the performance between x86 and x64. In reality you won't see much difference but it will execute faster. When rendering the 2000 heads they were the same because the bottle neck was the GPU not the CPU so thats why the lower count was faster.

The main reason for a x64 build is so you can access all system ram in x86 you are limited. And having access to this extra ram can of course improve your projects performance as you can cache more in ram than you could in a x86 build. (This applies to x86 native and x86 running on a x64 OS)

if I try using your mogre.dll I get a "Could not load file or assembly 'Mogre.dll' or one of its dependencies. The specified module could not be found." error. Do I need to copy over more than just the .dll?

Cygon, it would be nice to know which are the depencies of your Mogre build.

Perhaps update DirectX?
Or install vcredist for VisualStudio 2010?

I have installed vc redist 2010 , dx updatet by online updater-all works fine. Maybe i missed something:)

You need to copy the dlls from:
.\References\ogre\msvc-10.0-x86\
.\References\mogre\net-4.0-x86\
.\References\freeimage\msvc-10.0-x86\
.\References\tr1boost\msvc-10.0-x86\
.\References\cg\msvc-10.0-x86\ (for Cg)
.\References\mois\net-4.0-x86\ (for Mois)
.\References\ois\msvc-10.0-x86\ (for Mois)
(or 'x64' if you want to use the 64-bit version)

Now I had time to try all configurations/render systems/architectures. All were running fine and stable. Besides of the already mentioned performance differences there is no difference between all of them. Thanks for your awesome contribution!

Just three questions:

1. Is this build fully compatible with Ogre 1.7.3 (except for the new Terrain Component)?[/*:m]
   
2. Do I not need anymore Debug or Release versions of the Mogre and Ogre dlls? The same for both configurations?[/*:m]
   
3. What do I need the "tr1boost.dll" in my execution directory for?[/*:m][/list:u]

I expect the new binary file. Only get mogre.

Is this build fully compatible with Ogre 1.7.3 (except for the new Terrain Component)?
I suppose the new build contains the same features as Mogre 1.7.1.
Mogre 1.7 is mostly compatible with Ogre 1.7. (Although a few parts are not wrapped.)

The exact dependencies are:

1. DirectX June 2010 (I compiled Ogre against the June 2010 DirectX SDK)[/*:m]
   
2. Visual C++ 2010 SP1 runtime (every single binary in this build is compiled with that compiler and uses the DLL runtime)[/*:m]
   
3. An SSE2-capable CPU (I enabled it in all projects since it improves performance and I think all Pentium IIIs and Athlon XPs have been phased out by now)[/*:m][/list:u]
   Thanks @smiley80 for the DLL list! That's exactly what needs to be in the output directory.
   Sidenote: some people just dump such DLLs into the bin\Debug or bin\Release directories by hand, but since the 'bin' directory typically isn't committed to a VCS and everyone downloading a working copy would have to do additional steps then, it's better to add those DLLs as files to the project and use the "Copy to Output Directory" feature. This is what the "MogreDependencies" project in my example does. I used a separate project so I don't clutter up the main project.
   
   The easiest way to use this Mogre build in a new project would be to just take the "References" and "MogreDependencies" from my example, then add a reference to Mogre.dll and to the MogreDependencies project.

Great - thanks Cygon.

every single binary in this build is compiled with that compile and uses the DLL runtime
This should be fine for binary compatibility.
(Because in the past I read that there can be conflicts when using binaries which are build from different VS versions. Even binaries of VS2010 with/without SP1 should not be mixed.)

Now I had time to try all configurations/render systems/architectures. All were running fine and stable. Besides of the already mentioned performance differences there is no difference between all of them. Thanks for your awesome contribution!
Sweet! I've been running it through its paces, too (well, as good as a novice Mogre/Ogre user can at least) and anything that worked with 1.7.1 worked with my build as well. Only problem I noticed was that I have the wrong "OgreBuildSettings.h" in the References\Ogre\Include\ directory. I'll upload a new package with the right file, but this would only affect people trying to use Ogre from C++ without .NET.

Is this build fully compatible with Ogre 1.7.3 (except for the new Terrain Component)?
I used the patches from Mogre's repository (https://bitbucket.org/mogre/mogre/), so for the exact state, you'd have to ask one of the actual Mogre developers. It should have at least everything from the 1.7.1 build plus any wrapping code that has been added to the trunk since then. I didn't do any work to add new features introduced by Ogre since 1.7.1 myself.

Do I not need anymore Debug or Release versions of the Mogre and Ogre dlls? The same for both configurations?
Use the same for both configurations. There is no problem in linking to a release DLL from a debug build (you do it all the time with User32.dll, GDI32.dll, System32.dll), that's only an issue for static libraries. The only gain a debug build of Mogre+Ogre might bring you would be from assert()s placed in Ogre's sources, but Ogre's design favors outputting warnings to its log instead, so there's nothing lost.

What do I need the "tr1boost.dll" in my execution directory for
It contains the backing code of Boost (date_time, regexp and math). Vanilla Ogre links to Boost as a static library, but then you end up with one additional copy of the Boost code in memory for each Ogre DLL, which I considered wasteful, so I compiled the required parts as a DLL. The "Tr1Boost" name is because it's a minimal subset of Boost, containing only the headers required by Ogre and to support C++ TR1 in Visual C++ 2010 SP1. Only 902 headers instead of 8597 for Boost 1.47

I have updated the package again, replacing the wrong OgreBuildSettings.h with the right one. Only download if you're a perfectionist or intend to use this as an Ogre SDK for compiling native C++ applications as well.

I've also uploaded a second archive containing detailed instructions, the solutions I used and patches with my changes. There's nothing in there that I believe should be added to the Mogre repository -- my size reduction patch modifies the code generated by AutoWrap, but it would be much better to instead extend AutoWrap so the work doesn't have to be done anew for each future release. The rest is basically just Visual Studio projects that I created, including projects for Ogre and all its plugins that are rather pointless because CMake gets the job done as well

Not sure if and when I can tackle Hydrax and some of the other 3rd party addons, I still haven't fully figured out how to use paged terrain yet.

A minor off topic note: I'm finding it pretty hard to decide between Mogre, Axiom or possibly Unity. Mogre does a much better job staying up to date with Ogre and it appears to have fewer problems, too. If something goes wrong, however, I noticed it's a lot of work because the debug,test cycle is pretty slow (well, at least I've got VS solutions for everything now, so I can just change the code, hit F5 and go away :p). Regarding Unity, I don't know how well the Blender -> Unity asset creation part is developed, but I like the fact that I can completely skip the game logic infrastructure with Unity (the part that manages game entities, integrates physics, runs scripts, performs map changes, etc.). I'm not qualified to make a fair comparison, but maybe I'll blog about how easy I found each one to pick up!

I've also uploaded a second archive containing detailed instructions, the solutions I used and patches with my changes.

This is very useful for all people who want to compile (or update) Mogre.


I still haven't fully figured out how to use paged terrain yet.
There are 2 components. The "terrain component" and the "paging component".
I suppose the paging component is an optional addition for the terrain component.
Unfortunately I don't know how to use it. Perhaps the components have to be included in the file plugins.cfg.

The Ogre source code of these components seems to be well, but needs some improvements (e.g. performance, graphical bugs).
Currently the terrain (and paging?) component will be improved, because Google support its development in the Google Summer of Code 2011. Details are here.


I'm finding it pretty hard to decide between Mogre, Axiom or possibly Unity.
Thanks for your feedback.

@Cygon: Thank you for your answers!

I'm not qualified to make a fair comparison, but maybe I'll blog about how easy I found each one to pick up!
This will be interesting for everyone to read and to decide (if not already done).

Cygon, do you know the Mogre XML commentation tool?
a tool which creates the XML comments file (Mogre.xml) from Mogre.dll and the Doxygen XML output of Ogre. Including this file in a Mogre project shows comments for Mogre members in Visual Studio.

If you don't know it, you should try it.


By the way:
User McDonte finished the Mogre.Builder tool. Now he wants to create a GUI for more comfortable usage. (He will publish it soon.)
Maybe this also interesting for you.
Nice would be if your updated Mogre 1.7.3 version works with the build tool, too.
Or did you create your own tool to build different Mogre configurations?

I'm finding it pretty hard to decide between Mogre, Axiom or possibly Unity.
You also can have a look to the NeoAxis game engine.
Maybe it fits your needs, too.
http://www.ogre3d.org/2011/07/02/neoaxi ... 0-released

You also can have a look to the NeoAxis game engine.
But NeoAxis is not avaibale for free as the others are. There is one version for noncommercial use but you will always have a watermark... even Unity is offering a (slightly reduced) free version.

I've found that neoaxis is incredibly new user unfriendly. They basically say "so you want to make a game? Okay, take our showcase demo, and build off of it. It isn't commented very well and we don't have any decent tutorials. There is no 'clean' source you can build off of. Have fun!"

This weekend I tried use your builds in my main application.

First I needed to install VS 2010 (because VS 2008 has no .NET 4.0 support). Then install SP1 and documentation updates.
Very time killing. ... So I was sitting in my garden and read a book.

Then I got trouble:

Reason 1: ... I got strange exceptions and Visual Studio asked for cpp files, which names I don't have on my hard drive (e.g. ogrenewt_world.cpp).
... After a while I found recognized, that MogreNewt.dll needs the file newton.dll. (In previous versions the file MogreNewt.dll contained newton.dll.)

Reason 2: ... There were further strange exceptions
... Later I found out, it's because from Ogre 1.6 to 1.7 some internals were changed.

After solving the time killing problems I got this result:

My application uses Mogre and MogreNewt.
The upgrade to your 1.7.3 builds (x86) was successful and everything works fine.
Well, I use only a few Newton methods (for collision detection, no physics), but in general MogreNewt works.

In the past I tried a 1.7 bundle of Mogre & MogreNewt, but by an unknown reason it caused an exception at RenderOneFrame() when I enabled MogreNewt functionality in my application. So I had to stay with Mogre 1.6.

Now I'm happy that I can use your Mogre build instead, because:
* I can use a new API function which I missed in Mogre 1.6.
* Now my WPF GUI can use a much more better text rendering. (Without .NET 4 text in WPF was very blurred.) Additionally I can use some WPF functions, which I missed in .NET 3.5.

Thank you, Cygon !!


By the way:
What do you think about to include newton.dll to MogreNewt.dll?
(I suppose this is called a static link.)

@Beauty:
Did you have problems with Mogre itself or only with MogreNewt?
Because I tried the Mogre binaries and they worked fine, alone and with other Mogre addons (MHydrax test).

I never used MogreNewt before but since we have such a nice up-to-date warpper available I will maybe take a look. Can you post the steps you needed to take before you got it running?

Did you have problems with Mogre itself or only with MogreNewt?
When I used the Mogre 1.7.1 binaries without MogreNewt, my application runned fine.

I suppose my problems were related to MogreNewt.

Perhaps MogreNewt was build with another linked Mogre 1.7.x version?? This could be a reason.
But as far as I know the binaries for Mogre and MogreNewt were offered as bundle.
I don't know. I just stopped my tests when I recognized the strange problems.
My bug report I posted here. (November 2010)

So (in the past) I stayed with Mogre 1.6.5 and a simplified alpha version of MogreNewt. It was the first Mogre wrapper for Newton 2.

Can you post the steps you needed to take before you got it running?
I just tried the binaries of Cygon and had no problems.
For MogreNewt you need the files MogreNewt.dll and Newton.dll. Both you find in the archive of Cygon.

MogreNewt hat some nice visual debugging functions.
Unfortunately there is not much documentation related to Mogre. But you find useful information on other places.

Forum topic Mogrenewt 2.0 [Binary on first post]
... Main discussion topic for MogreNewt

MogreNewt wiki page
... There I wrote where to get information about Newton functionality and I added a link list.

Mogre binaries and they worked fine, alone and with other Mogre addons (MHydrax test)
Nice to hear that the MHydrax wrapper works fine with Mogre 1.7.
Today I talked with user Jo0oker who uses MHydrax, too. He also has no problems with it.

I remember some problems of the MHydrax forum topic. Perhaps they are solved or just happens in special cases?
I got a code example from Jo0oker and posted it in the wiki. (here)

I encountered only one problem with MHydrax, but I am not sure if it is related to changes in Ogre 1.7.3 or a problem of the wrapper. It did not happen for Mogre 1.7.1 when I tried MHydray the first time. It could also be related to Hydrax 0.5.3 that I used for building MHydrax.
As soon as I got some time and my first own compiled version of Mogre I will do some further tests.

By the way: nice wiki page, extremly useful to beginners. I did not like the MHydrax samples provided with the wrapper. I translated the comments and added VB.Net code to it (I hope it is all right, because I only used the converter and did not test it).

If you want to use the new Terrain and Paging component in Mogre you can do this! I just found out when I looked onto Cygon's binaries then I saw that all needed classes has already been wrapped. This is because Cygon compiled the Mogre branch TerrainAndPaging and provided these binaries.

Mstoyke said that this wrapper is (pre)alpha but it already works.

Cygon, you are great!!
Before you compiled everything from the base, nobody was able to try/use the new Mogre terrain wrapper.
Now we can do - thank you very much again.
(In my eyes you are like a developer guru.)

McDonte also ported the Terrain Tutorial for usage with Mogre. His code is here.

My post with wrong content:
Also I see, that Cygon added/compiled the wrapper for Particle Universe.
This is also useful for everybody who wants to use this powerful plugin for nice particle effects.
Cygon, thank you again.
(If I remember right, other people had problems to compile this undocumented wrapper.)
Did anybody this the Particle Universe wrapper of this Cycon build?

Correction:
I think I was wrong.
I saw the file "Plugin_ParticleFX.dll" in Cygons binary package and thought this is the PU wrapper.
Now I remember that this should be just the Ogre default particle plugin.

Cygon, if you are interested in usage of the Particle Universe plugin, you can find the undocumented wrapper code here:
http://www.ogre3d.org/tikiwiki/PUDotNet
The related forum topic is here.

You remove pdb files.

You remove pdb files.
Since he is only providing release binaries.

I'm finding it pretty hard to decide between Mogre, Axiom or possibly Unity.

Mogre does a much better job staying up to date with Ogre and it appears to have fewer problems, too. If something goes wrong, however, I noticed it's a lot of work because the debug,test cycle is pretty slow (well, at least I've got VS solutions for everything now, so I can just change the code, hit F5 and go away :p). Regarding Unity, I don't know how well the Blender -> Unity asset creation part is developed, but I like the fact that I can completely skip the game logic infrastructure with Unity (the part that manages game entities, integrates physics, runs scripts, performs map changes, etc.). I'm not qualified to make a fair comparison, but maybe I'll blog about how easy I found each one to pick up!

Hi Cygon,

you were not logged in to our forum for about 3 months now.
Are you still interested in Mogre or did you decide for an other 3D solution?
If you use an other solution, I would like to know more.

By the way:
For Ogre 1.8 the RC1 was released (details). The official 1.8 version should published forthcomming.
An overview of the new features you find here. If I understood right, DirectX 11 is (fully?) supported now.
If you are interest to update Mogre for 1.8, you will find useful links (e.g. to the autowrapper documentation) here.

Ogre's new version is out(v1.7.4). Will there be a new build version for Mogre?

Hey there!
'seems I wasn't subscribed to this thread, otherwise I would have posted a reply earlier, sorry

zarfius woke me up to his thread My mission to build a better Mogre.

I haven't updated my builds to 1.7.4 yet and I'm not currently working on anything using Mogre right now, so while I could sit down and create another set of binaries for 1.7.4, maybe I can instead render some assistance to his efforts creating a MogreBuilder-based automatic build solution. It's certainly more future proof than my one-off build (which would be classed as "manual labor" on any automation scale )

Hey there!
'seems I wasn't subscribed to this thread, otherwise I would have posted a reply earlier, sorry

zarfius woke me up to his thread My mission to build a better Mogre.

I haven't updated my builds to 1.7.4 yet and I'm not currently working on anything using Mogre right now, so while I could sit down and create another set of binaries for 1.7.4, maybe I can instead render some assistance to his efforts creating a MogreBuilder-based automatic build solution. It's certainly more future proof than my one-off build (which would be classed as "manual labor" on any automation scale )

This is now complete You can get version 1.7.4 with Terrain and Paging from my blog. Thanks Cygon for all your help.

What do I do with the newer OIS.dll? At the moment I just have a MOIS.dll from 1.6... is this now part of Mogre.dll and it just calls things in OIS.dll, or what?

EDIT: also I'm not using the terrain, paging, or RT shader system but I have to include those dlls to get it to run, how do I fix that?

Also do I need any PDBs?

What do I do with the newer OIS.dll? At the moment I just have a MOIS.dll from 1.6... is this now part of Mogre.dll and it just calls things in OIS.dll, or what?
I'm not sure if it's required. I doubt it, but the MogreBuilder includes it when it collects up the binaries. Right now it's not my top concern, but if you want to investigate it please do I'll keep it in mind next time I'm working on it.

EDIT: also I'm not using the terrain, paging, or RT shader system but I have to include those dlls to get it to run, how do I fix that?
Yes, I noticed that too. I'm not sure how to fix it yet though. Still, it's better to have Terrain and Paging than not right?

Also do I need any PDBs?
Nope. You don't need them and they are pretty large in the download. I think they make debugging easier but I typically don't use them myself. If it's really important I could probably provide them in a separate download link or you could build it yourself. After all, that's what the MogreBuilder makes easy

What do I do with the newer OIS.dll? At the moment I just have a MOIS.dll from 1.6... is this now part of Mogre.dll and it just calls things in OIS.dll, or what?
I'm not sure if it's required. I doubt it, but the MogreBuilder includes it when it collects up the binaries. Right now it's not my top concern, but if you want to investigate it please do I'll keep it in mind next time I'm working on it.

I can quite happily exclude it and it seems to work okay, so I guess it doesn't need it

Also do I need any PDBs?
Nope. You don't need them and they are pretty large in the download. I think they make debugging easier but I typically don't use them myself. If it's really important I could probably provide them in a separate download link or you could build it yourself. After all, that's what the MogreBuilder makes easy

I haven't look at it yet, but is it as easy as just pressing a few buttons and it builds, or do I need to install a bunch of things first then build it? Just asking because I always find compiling big c++ things scary ;__;

I haven't look at it yet, but is it as easy as just pressing a few buttons and it builds, or do I need to install a bunch of things first then build it? Just asking because I always find compiling big c++ things scary ;__;

Yeah it's pretty easy. As long as you have Visual Studio, TortoiseHg and CMake it's just a matter of running the builder. There is a readme file with a some instructions, you can read it on the bitbucket repository here:
https://bitbucket.org/mogre/mogrebuilder/overview

The build process does take a long time (around 30 - 45 minutes) but aside from that it's relatively painless now.

I haven't look at it yet, but is it as easy as just pressing a few buttons and it builds, or do I need to install a bunch of things first then build it? Just asking because I always find compiling big c++ things scary ;__;

Yeah it's pretty easy. As long as you have Visual Studio, TortoiseHg and CMake it's just a matter of running the builder. There is a readme file with a some instructions, you can read it on the bitbucket repository here:
https://bitbucket.org/mogre/mogrebuilder/overview

Alright, I'll give it a whirl

The build process does take a long time (around 30 - 45 minutes) but aside from that it's relatively painless now.
UGH. This is one reason why I like c# a lot more than c++ :D

Hi there,

I like Cygon's binary package provided on first page of this thread, it's "nearly" complete with all it's included components.
However I was missing my favourite HydraX component, so I decided to compile it myself,
luckily you offered the include files in your package

You can download the binaries of my "HydraX extension" here:
http://zds-server.de/mogre_173_cygonpac ... ension.rar

Simply extract them to the "/References" subfolder included in the mainpackage,
I tried to stick to Cygon's naming scheme.
I also did not statically link in the HydraX into MHydraX.
You have to copy BOTH .dll to your mogre's application working dir (i. e. /bin/debug/)
However unlike his components, this extension does not contain x64 builds of hydrax.

I also included the small patches for HydraX 0.5.1 sources to work with Ogre 1.7 into the patches folder,
however the credits for this go the the corresponding threads in forum.
(viewtopic.php?f=20&t=10124&p=58849#p58848)

I also did not deactivate boost (as Cygon's package is also using it),
but actually the boost include dir from Cygon's package seemed to be quite incomplete,
so I build against a full set of boost 1.47 headers (~72mb size, subfolder "Boost").
http://www.boostpro.com/download/

Finally I reorganised the hydrax include files into a single directory, don't get confused about that.

Please note: I'm still pretty new to Ogre/Mogre,
but as far as I can tell, I can see water here so I suppose it's working
Your feedback is welcome anyways.

Now I'm gonna go figure out how to get an updated SkyX working with this package...

kind regards

Hi there, it's me again

I tried to get SkyX working with Cygon's Package, however I ran into some trouble.
I started with compiling the current SkyX 0.2.1 sources (http://www.paradise-studios.net/downloads/hydrax_skyx/)
against Cygon's includes/libs, but after integrating the .dll I realized, that an essential part is missing in the original sources:
There are no EXPORT statements for the C++ stuff in the original SkyX sources by default.

This means the C# wrapper classes from the following SVN do not work together with a plain SkyX, simply because their PINVOKE targets do not exist:
http://code.google.com/p/skyxmogre/

So my next approach was to use the SkyX sources/version from the skyxmogre-svn above, which include all the necessary PINVOKE EXPORT declarations.
I compiled these sources against the Cygon Pack. It's nearly working, except for the "CloudsManager".

If I uncomment the "CloudsManager.Add(..)" line below, then I get an "AccessViolationException".
If I leave it commented, SkyX is working with day/night, sun/moon and so on.


SkyManager = new SkyX.SkyManager(SceneManager, Camera);
SkyManager.Create();
//SkyManager.CloudsManager.Add(new CloudLayer.LayerOptions());

...
SkyManager.Update(evt.timeSinceLastFrame);


I'm afraid, I currently have no idea what's going wrong there.
So any help would be appreciated.
I will try to have a look at it again soon, may be I can figure it out.
I think I will try to compile the native C++ demos next, let's see wether they're working or not..

So far you can download both SkyX binaries (original 0.2.1-build without PINVOKE EXPORTS + skymogresources-build with PINVOKE EXPORTS) for testing purposes here,
but keep in mind what I've been writing about their stability above:
[link removed, see stable package below]

kind regards

edit: I found the solution, it's already in the forum
viewtopic.php?f=8&t=13172&start=45

I've uploaded a new binary package with "fully" working SkyX for Cygon's Mogre Pack,
like for the hydraX I included the patch that needs to be put on top of the skyxmogresvn-sources to fix the issue with the cloudsmanager:
http://www.zds-server.de/mogre_173_cygo ... ension.rar

There is still the plain skyx-0.2.1 included (folder: skyx-without-exports).
However you most likely will want to use the "skyx" folder (combined with the wrapper classes from skyxmogresvn),
since we're talking about mogre here...

It's me again, got something for u

After having the new terrain-system working with this Cygon-Pack, I became frustrated when realizing there are no collisions from Newton yet...
That, for sure, was not an acceptable situation for me.

To have collisions with the new terrain system, you have to use the "HeightFieldCollision" from the Newton library.
Unfortunately it (was not yet) wrapped in MogreNewt.

I would have had no idea how to implement it, if there wouldn't have been this nice posting:
viewtopic.php?f=4&t=13400

So I tried my best to implement this into the MogreNewt (instead of OgreNewt like in forumthread) used in this Cygon's Pack and finally I (think) it's working.
I've added the "HeightField" class to the MogreNewt C++ CLI just like in the linked thread, however the code there does automatically create a NewtonBody, what is not suitable for usage with Mogre. (You won't have any reference to that body then, cause we usually create them within Mogre with "new Body(...)" ). So I had to write some "extra" code.
I'm for sure are noob @ C++, so please don't expect well written code, but as it was just a few lines of code and I just tried to "copy style" from existing code I somehow managed to do it...

You can download a prebuild MogreNewt.dll with included "HeightField" CollisionPrimitive here:
http://zds-server.de/mogre_173_cygonpac ... ension.rar

Things to know:
1) The archive is structured like the other ones above, first step: just extract them to your /References folder from Cygon's pack, to "merge" mainpackage/these extensions.
2) This MogreNewt.dll is build against the Newton include/libs from Cygon's Pack (which is 2.33 just as before..), however this MogreNewt.dll doesn't have a Newton.dll compiled in, so you have to copy the Newton.dll from Cygon's Pack together with the new MogreNewt.dll to your app directory to use it.
3) Like for the other packages, I've integrated the used patches in subfolder "/patches", you can have a look at my "diry" implementation of HeightField there. This new MogreNewt.dll is based on latest MogreNewt-SVN + Cygon's Patch + my patches...

How to use:
Just like any other CollisionPrimitive...
You have to pass your terrain in constructor of "HeightField".
Here's a small code snippet..

// create terrainbody
// yourTerrain --> an object of class terrain to create the collision for, get it from your TerrainGroup
// NewtonWorld --> an object of class "World", you should know that anyways....
// TerrainNode --> a SceneNode object to link with the terrainbody
using (MogreNewt.CollisionPrimitives.HeightField colWorld = new MogreNewt.CollisionPrimitives.HeightField(NewtonWorld, yourTerrain, 1))
{
TerrainBody = new Body(NewtonWorld, colWorld);
TerrainBody.AttachNode(TerrainNode);
TerrainBody.SetMassMatrix(10000.0f, new Mogre.Vector3(0.0f, 1.0f, 0.0f));
TerrainBody.IsGravityEnabled = false;
}


kind regards

I have successfully build Mogre in x64 and I still can't get it working. I always get an exception: FileNotFoundException with the instruction CreateRoot().

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Mogre;
using System.Windows.Forms;

namespace ConsoleApplication1
{
class Program
{
protected static Root mRoot;

static void Main(string[] args)
{
CreateRoot();
}

protected static void CreateRoot()
{
mRoot = new Root();
}

}
}

It should work, I don't know what to do

Hey Sigvald,

actually I think it's little bit offtopic, except you try to rebuild Cygon's x64 version

However:
Can you be little more specific on the Mogre sources you're trying to build?
Where did you get them? What patches did you apply?
What Ogre are you linking against during build, did you build Ogre yourself too?

Your error-message at the situation you're receiving it pretty much sounds like you're just missing one of the depedencies.
(like OgreMain.dll or others from linked Ogre binaries)...

kind regards

[...]actually I think it's little bit offtopic, except you try to rebuild Cygon's x64 version
Sorry, I thought it was a topic talking about any x64/x86 builds of Mogre.
Can you be little more specific on the Mogre sources you're trying to build?
I followed those tutorials:
- http://www.ogre3d.org/tikiwiki/Building ... ep+By+Step
- http://www.ogre3d.org/tikiwiki/How+to+c ... 64+systems
Where did you get them? What patches did you apply?
I got every files from the bitbucket repository. I applied the patch 58266f25ccd2.patch
What Ogre are you linking against during build, did you build Ogre yourself too?
I build Ogre myself too, I followed the tutorial.
Your error-message at the situation you're receiving it pretty much sounds like you're just missing one of the depedencies.
(like OgreMain.dll or others from linked Ogre binaries)...
I build everything :/

Hi sigvald,

I'm afraid I can't help you any further, because I lack experience with building x64
However, based on your errormessage, I would still assume you're just missing a dependency you included during build, but you did not copy the corresponding .dll

May be check the following:
1) There is a ogre.log file, I guess you've already checked it and there's no more useful information in it? If not, go check it
2) The CMake configure of Ogre gives you some feedback about the found dependencies it is going to include into the build process, this may vary from environment to environment. You need to make sure, you later copy in all the referencing dll the CMake script registered and that are not built into OgreMain.dll.... That could be something like: OIS, Boost and even more. Keep in mind: There are more possible dependencies that may be found on your system during CMake configure than the ones in the "depencies package/subfolder.. For example the boost...
3) The new ogre with included terrain support creates more than just OgreMain.dll, probably you'll have a OgreTerrain.dll and OgrePaging.dll and may be even more .dll you have to copy to your folder to. May be you want to post a list of the .dlls you copied to your directory so far, so someone can check wether it seems complete?
4) You may also want to check your "plugins.cfg" and make sure you the given path is correct and you do not load any non-existing plugins. (pretty much guess this is not your problem at all..)
5) Some of the dependencies are also compiled into the OgreMain.dll, as you usually don't need to copy (all) of the dependencies dll. Some are usually not compiled into (like OIS) Make sure you did not change anything of these settings or for example try copying the raw dependencies .dll files additionally into your app directory in case you somehow managed to exclude the usually included ones from the OgreMain.dll.
6) Try other things
Whatever... reinstall DirectX SDK, reinstall VS 2010 x64 Runtime, start praying...

If nothing helps, why don't stick with cygon's x64 pack? It's a pretty good point to start and once you're more experienced with Ogre/Mogre you surely will find out how to build it yourself.

kind regards

You might also want to make sure that you're actually running the application from the folder that has the DLL's in it. If your building out of Visual Studio the default is going to be bin\Debug or bin\Release. However, be careful with dumping all your binaries and media in that folder, because the build process could clear it out.

What I do is add the required DLL's to my solution as link's and set them to 'copy if newer' so that they get copied to the output directory on build. Another approach is to setup a post-build step.

For debbugging this problem, you can add a line to your code before calling new Root() that checks the current directory.
string path = Directory.GetCurrentDirectory();
Console.WriteLine(path);
or
MessageBox.Show(path);

Also, to try and eliminite any other problems make sure you can get it working with a set of binaries that you know work (like the official ones or Cygon's pack).

Lastly, have you seen the MogreBuilder project? It automates the build process rather than following through the build steps manually in the tutorial. Currently it doesn't do the x64 binaries, but it might not be too hard to add them (I haven't tried).

I finally found where my problem was. I used Dependency Walker to see if anything was missing and there was something, IESHIMS.DLL

Here is a feedback from an other topic:
Cygons x64 build is extremely stable under multithreading.

Hi all,
I have a big problem with this release of Mogre. I've created a simple project with VS 2012 on Windows 7 64 bit, and everyting works well, but if I try to copy the project on a PC with Windows 8 64 bit and try to launch it (always on VS 2012), I obtain this error:
"System.AccessViolationException" in Mogre.dll "Attempted to read or write protected memory. This is often an indication that other memory is corrupt"
The error appear when I use the function ResourceGroupManager.Singleton.AddResourceLocation in this procedure:

Private Sub DefineResources(ListaModuli() As String)
predStringEqual = New Predicate(Of String)(AddressOf isStringEqual)
Dim cf = New ConfigFile()
cf.Load("Ogre\resources.cfg", vbTab & ":=", True)
Dim section = cf.GetSectionIterator()
While (section.MoveNext())
stringaConfronto = section.CurrentKey
If Array.Exists(ListaModuli, predStringEqual) Then
For Each line In section.Current
ResourceGroupManager.Singleton.AddResourceLocation(line.Value, line.Key, section.CurrentKey)
Next
End If
End While
End Sub

Can you explain me how to solve the problem?

"MemoryViolationExceptions" is a typically error while using Mogre.
Some notes about I wrote here:
viewtopic.php?p=102116#p102116

Check this:
Have a look to your ogre.log file
Did you get the latest revision of DirectX 9.0c?
. . . . . Microsoft releases updates from time to time (althouth the version number doesn't changes)
. . . . . Use the web installer to be shure that you get the latest revision: http://www.microsoft.com/en-us/download ... aspx?id=35
Did you install graphic drivers? (Intel cards cause often trouble, sometimes also mobile versions of NVidia/AMD cards in notebooks)
If you use DLL files, which were created by a different Visual Studio version (or with Version xxx SP1 or xxx SP2), then you need to install the related "Visual C++ Redistributable Package", which contains needed depency files of specific Visial Studio versions.
. . . . . Try this by install all x86 packages for VS 2008, VS 2008 SP1, VS 2010, VS 2010 SP1
. . . . . You find them here: http://search.microsoft.com/en-us/Downl ... 86&x=0&y=0

By the way - most improvements of the Cygon build were included to the official Mogre source code.
Here you find precompiled binary packages for Mogre 1.7.3: viewtopic.php?t=29714&f=8
It's also very easy to compile Mogre on your own by use of the MogreBuilder. (look to wiki page and repository)

Good luck!

Hello Beauty,
thank you for your answer. I've not tried your suggestions because I've found a way to solve the problem.
The error appears if my resources.cfg file is this:

[Monitor]
FileSystem=Media/materials
FileSystem=Media/meshes

But I have no problems if I modify it in this way:

[Monitor]
Zip=Media/materials/Materials.zip
Zip=Media/meshes/Meshes.zip

So I solved the problem copying my resources in two .zip files.
Do you think is it better if I verify all your controls?

Strange, but nice that you found a solution.

FileSystem=Media/materials
This way works for my application.
Note: Relative paths (like in your example) are relative to the directory of your binary directory.
By the way: I don't have paths in the [monitor] section. In my config file the section name is [General].
Mayby try this: FileSystem=Media/materials/*.*