History: Mogre FAQ

Source of version: 10 (current)

{maketoc}

!General

!! What's about the performance hit of using Mogre compared to Ogre?

* 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. {SUP()}answer by user koirat{SUP}

* 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. {SUP()}answer by user Beauty{SUP}


!! How to debug Mogre and Ogre in Visual Studio
Mogre is only a very small layer over Ogre so there's not much to debug (except maybe for the ((MOGRE pure .NET classes|Mogre's pure .NET classes))). It's far more interesting to step into Ogre's sources with a debugger. To be able to do so, the following requirements must be met:

* You need debug builds for Ogre and Mogre. The safest way to get them is to ((Building MOGRE from source|compile Mogre yourself)).
* In the project settings of your Mogre (.NET) project enable "Enable unmanaged code debugging" in the "Debug" section.

__Note:__ When unmanaged code debugging is enable starting a debug process needs more time.


!Comparison with other engines

!!Unity, Visual 3d.NET, Torque X

Found in [http://www.ogre3d.org/addonforums/viewtopic.php?p=74646#p74646|this forum thread]. 
It also contains a further discussion, e.g. about Axiom, XNA.

__Unity:__
* Unity costs $1200 if you want the un-gimped engine, which is a pretty big expense for a hobby project and a large deterrent to recruiting others to help on the project, so I suspect Unity is not a viable choice despite the fact that it has a good pipeline.
* Unity also has a somewhat strange dev environment where you attach "scripts" to visual objects. While this works, it also makes me shudder to think what a large-scale project will look like over time and how disorganized it would become.

__Visual 3d.Net:__
* Visual 3d.Net, while less costly than Unity, is still not free, thus again is a barrier to recruitment
* I was initially excited about using this, despite the cost, however, as I kept waiting and waiting for their promised next version, I began to realize that the engine seems to be in trouble and I cannot rely on them to come out with features that I need in any kind of reasonable time frame. Disappointingly, I've mostly given up on this engine - which is too bad considering how much potential it has.

__Torque X:__
* cost is not free, but low enough that I think it's reasonable for a hobby project
* Theoretically has everything I need/want... however, based on reading it seems the current version is virtually unsupported and buggy as hell. It's also a nightmare to work with based on my trial with it. The devs are supposedly re-vamping Torque X, but with the plans I've read, I don't expect real results for another 1-2 years at least.



!!Unity, 3D Rad, Blender 3D game engine, OgreKit, JavaMonkeyEngine

Found in [http://www.ogre3d.org/addonforums/viewtopic.php?p=77853#p77853|this forum post]. 

__Unity:__
* Indie version is free (however don't know if one can create commersial application with it), pro version is expensive.
* pro: can script with javascipt / C#
* con: indie version does not have all the good things that pro version have.

__3D Rad:__
* pro: reads .x files
* pro: good physic engine and easy link objects to physics etc
* pro: uses angelscript, C -like scripting language
* con: loading objects to the editor, it is complicated
* con: shadowing system sucks
* con: not open source, so cant modify it the way I wanted (can ask if developer to add new feature but it costs money)

__Blender 3D game engine:__
* pro: integrated to blender, so modelling can be done quick, and these are in game engine immediately
* pro: physics, quite easy setup
* con: using fonts isnt made easy
* con: cant use with commersial applications, because of that blend player's license, and it cant be sold with own blender game

__OgreKit:__
* pro: reads .blend files
* pro: physics, sounds etc works, that are setuped in blender
* con: does not support all of the blender's game engine's logic
* con: scripting with LUA (arggg!! I dont like lua/python scripting languages, too hard and complicated to me, and I have no time to learn new programming language from the start)
* Of course one can use ogrekit and code all in c++ but I dont want use it anymore either

__Others:__
* Then I tried some other game engine but always noticed that there arent free.
* Then I installed java, netbeans, and downloaded jMe (JavaMonkeyEngine). It have own editor, modified netbeans. It doesn't work very well yet, it and newer jme is at alpha stage. Then I thinked twise, that no more java. When used C#, there is no point turning to java again.

__Mogre:__
* Then I switched back to Mogre and good things: C#, Ogre have good community so project does not die (hopefully mogre does not die either). One thing that I miss, is cross-platform support, but it isnt so necassary atm (for my projects).

%%%
!Usage

!!Why do some classes have the '___NativePtr'__ postfix ?
These are not classes but [http://msdn2.microsoft.com/en-us/library/saxz13w4.aspx|structs]; they offer better performance and put no pressure on the managed heap. They are mainly used for simple Ogre classes that are like C structs (they don't form inheritance chains and they mostly contain data). .NET structs are fundamentally different than classes and are used differently, so '___NativePtr'__ is appended so you can clearly distinguish them.

_NativePtr structs contain and pass around only the native pointer to the Ogre object. The guidelines for using them are:

* __Instantiation__ - When you '__new'__ a struct it's members get their default values, thus when you __new__ a _NativePtr struct you get a null native pointer. In order to create an Ogre object you have to call the static __Create__ method:

{CODE(wrap="1", colors="c#")} LayerBlendModeEx_NativePtr lbm_null = new LayerBlendModeEx_NativePtr();   // This returns a null native pointer
 LayerBlendModeEx_NativePtr lbm_obj = LayerBlendModeEx_NativePtr.Create(); // This creates the Ogre object and returns a pointer to it
{CODE}
* __Comparing__ - If you want to compare whether two _NativePtr objects refer to the same Ogre object use the __Equals__ method. Note that _NativePtr structs override the __Equals__ method and the '==' operator if the Ogre class overrides the '==' operator:



{CODE(wrap="1", colors="c#")} LayerBlendModeEx_NativePtr lbm1 = LayerBlendModeEx_NativePtr.Create();
 LayerBlendModeEx_NativePtr lbm2 = LayerBlendModeEx_NativePtr.Create();
 
 bool areEqual1 = lbm1.NativePtr == lbm2.NativePtr;  // They point to different objects, returns false
 bool areEqual2 = lbm1.Equals(lbm2);  // Ogre::LayerBlendModeEx overrides '==' to compare the values, returns true
 bool areEqual3 = lbm1 == lbm2;  // You can use '==' instead of Equals, returns true
{CODE}
* __Destroying__ - If you create a _NativePtr object, you must call the __DestroyNativePtr__ when you are finished with it, in order to delete the native Ogre object, otherwise there will be a memory leak (you can track memory leaks by using the debug Mogre.dll and checking 'OgreLeaks.log')



{CODE(wrap="1", colors="c#")}  lbm1.DestroyNativePtr();  // Delete the Ogre object
{CODE}
!!!Why do some classes have the 'Const_' prefix ?


This is only for classes that wrap STL containers (vector, list etc.). C++ uses the 'const' keyword to indicate that a parameter will not be modified by the method, or that the returned value should not be modified by the calling code. C# and VB.NET doesn't have a similar mechanism so, to avoid breaking the method 'contract', when a Ogre method accepts/returns a const STL container, the equivelant Mogre method accepts/returns a read-only 'Const_' STL wrapper class. The conversion from the normal STL wrapper to the Const_ one is implicit:
{CODE(wrap="1", colors="c#")} NameValuePairList list = new NameValuePairList();
 Const_NameValuePairList const_list = list;  // Implicit conversion{CODE}
__Note:__ This implicit conversion doesn't work for VB.NET (probably a VB.NET bug). Use the __ReadOnlyInstance__ property instead:
{CODE(wrap="1", colors="c#")} Dim const_list As Const_NameValuePairList = list.ReadOnlyInstance
{CODE}


!!I see a Renderable class and a IRenderable interface, isn't only one of them enough ?


Classes that are used with multiple inheritance by Ogre are converted to interfaces. For example, if there is an Ogre method that accepts/returns a Ogre::Renderable object, it will accept/return a Mogre.IRenderable when converted for Mogre. So when dealing with Ogre objects/methods you will use the interface.

But if you want to create a custom class that implements the interface, you can't just add it to the class definition; you will implement it on the .NET side but it won't be usable by Ogre. For these cases there is a class that you should derive from if you want to implement the interface. For example, in order to implement IRenderable, you should subclass the Renderable class.

!Troubleshooting
!!I'm getting a FileLoadException when I try to run a Mogre app on another machine
MOGRE is built using Visual Studio 8 SP1, so it requires the VC SP1 libraries. You need to [http://downloads.sourceforge.net/mogre/vcredist_x86.exe|install the SP1 vcredist_x86] on the target machine. (__Note:__ vcredist_x86 installs only the release libraries, so only the release binaries of Mogre will work.) Also, take a look at [http://www.ogre3d.org/phpBB2/viewtopic.php?p=210171|this post].

!!Why do I get a crash when I dispose Root ?
# If you are getting a crash only when using the OpenGL renderer and not with the Direct3D renderer, make sure that you are not disposing Root inside a finalizer. GL requires that it gets disposed by the same thread that created it, and finalizers run in a different thread than the main one.
# All SharedPtr objects (MaterialPtr, TexturePtr, GpuProgramPtr etc.) must be out of scope before disposing Root, so make sure that you clear all references of SharedPtr objects before the call (i.e. set your SharedPtr variables to null).

!!I get a crash, how can I see the line and the call stack ?
# Copy the 'OgreMain_d.pdb' file from 'C:\OgreSDK\lib' to your executable's debug directory (i.e. 'C:\OgreSDK\bin\debug')
# Go to your project's properties -> Debug and under 'Debug' Configuration check 'Enable unmanaged code debugging'.
# Debug your project and when the crash happens you should be able to see the call stack. If you download Mogre's source code you'll be able to select the source file to see what line is causing it.
# Note that to get the full stack trace, you must be linked to Mogre_d.dll in your .NET project (and the _d versions of any Mogre DLLs you link to), and in turn for that to work you must make sure your plugins.cfg refers to the _d versions of all the plugin DLLs. If you have done all of the above, you should be able to get a stack trace all the way into Ogre C++ code.

!!I get a System.BadImageFormatException within a 64-bit enviroment, what's wrong ?
The MOGRE assemblies are platform-specific and therefore generate some strange errors if you build them with standard Visual Studio settings within an 64-bit enviroment. You can force your application (eg. the samples) to run in WOW64 by going to the project properties in VS, select the "build" tab, and set the "platform target" to x86.
(Info provided by Lightbringer)

!!Set VC# 2008 Express to compile in x86
This looks like a scary long list, but it's really simple.
# In VC# Express 2005, go to {MONO()}Tools -> Options{MONO}.
# In the bottom-left corner of the Options dialog, check the box that says, "Show all settings".
# In the tree-view on the left hand side, select "Projects and Solutions".
# In the options on the right, check the box that says, "Show advanced build configuraions."
# Click OK.
# Go to {MONO()}Build -> Configuration Manager{MONO}...
# In the Platform column next to your project, click the combobox and select "<New...>".
# In the "New platform" setting, choose "x86".
# Click OK.
# Click Close.
Thanks very much to http://forums.xna.com/forums/t/4377.aspx#22601.
Working in Windows 7 64bits.

!!!Set your system so that it uses the 32bit CLR by-default (use this if the previous tip is not working)
If running in a 64bits Windows system, you can try to set your system so that it uses the 32bit CLR by-default.  You can do this by calling:
# Open a Command Prompt window with Administration rights
# "C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Ldr64.exe setwow"
# try to run your MOGRE app


Working in Windows 7 64bits RTM.
History: Mogre FAQ

Source of version: 10 (current)

Search by Tags

Latest Changes

Search

Online Users
