MOGREについて - MOGRE @ ウィキ

MOGREって何？

MOGRE (Managed OGRE)はOGREライブラリの.NET2.0ラッパーです。
C++と.NETの間を繋げるコードはC++/CLIを用いて開発されています。

Are there other options?

If you'd rather use another language, there are other wrappers available:

   * OgreDotNet - Another .NET Wrapper
   * Ogre4J - for Java
   * PyOgre - for Python 

If you want to stick with C# or VB.NET and don't want to use a wrapper, there is another option available to you: Axiom - C# Port of OGRE, which is now a part of the RealmForge project(no longer under development). Be warned, though, that ports have inherant pitfalls.
[edit]
Downfalls of using a ported project

   * Because a port requires the manual re-writing of code,
         o There is an increased chance of bugs being introduced to what started as already-stable.
         o It takes a long time to complete anything.
         o If the original project (OGRE) releases an upgrade, the port project (Axiom) has to pick through the entire original project, look for changes, and update the port project. This means new updates take a long time to be released. Quite often, updates from the last release aren't complete before the next release is out, making a "perpetual update" situation, instead of continued work on finishing the project as a whole, thats why axiom is so outdated in comparison with original ogre3d project. 
   * Because of changes made to the methods and structure by the porting team, your support community is reduced to only those who are also using the port.
   * OGRE makes extensive use of plugins. Plugins like the Paging Landscape Scene Manager also need to be ported for use with the ported version of OGRE also increasing the development time. 

Truthfully, the only reason for using a port is to avoid the very slight performance hit caused by a wrapper, but most of the time the disadvantageso of using a project like axiom outcomes the mostly not noticeable perfomance gain due to the increased complexity and increased development time of porting everything from ogre to axiom
[edit]
Benefits of using a wrapper

Using a wrapper for OGRE instead of a port has a few major benefits:

   * A complete port from C++ to C# is a huge project requiring a complete rewrite of the code. A wrapper merely exposes the existing C++ code to C# and VB.NET.
         o This means less chance of bugs being introduced
         o And also more chances of just updating the wrapped part to update the project to the most recent version 
   * The OGRE community is much larger and more capable of offering support.
   * OGRE itself is more fully-featured than the Axiom port.
   * Plugins don't care that the OGRE DLLs are wrapped, because they are loaded by the OgreDLLs themselves. Thus, there is no need to bother with porting, converting, or wrapping any of the plugins. 

A good way to think of it is that instead of reinventing the wheel, we're taking an existing wheel and making an adapter for it to work with a different vehicle.

One disadvantage is that the wrapper introduces a layer between your application and the rendering engine that effects execution speed. The degree of performance degradation, however, is minimal to the point of being not even noticeable (see OGRE-MOGRE interconnection)
[edit]
Comparing to OgreDotNet
[edit]
Advantages

The wrapping layer is as trasparent as possible; the user need not to be aware that he is accessing OGRE through a wrapper.

   * Compatible with newest OGRE version (1.4.6)
   * Easier to install and setup (no compiling needed, no SWIG needed)
   * Multiple C++ inheritance is handled by MOGRE using .NET interfaces (i.e. Renderable -> IRenderable)
   * The *Listener classes are replaced by .NET events. For example: 

public virtual void CreateFrameListener()
{

   root.FrameStarted += new FrameListener.FrameStartedHandler(ExampleApp_FrameStarted);

}

bool ExampleApp_FrameStarted(FrameEvent evt)
{

  ...
  return true;

}

   * Iterator classes are exposed as .NET Enumerators. For example: 

AnimationStateSet set = entity.AllAnimationStates;
foreach (AnimationState animState in set.GetAnimationStateIterator())
{

  MessageBox.Show(animState.AnimationName);

}

   * All SharedPtr classes are handled correctly meaning the .NET class will keep the SharedPtr from getting deleted until it (the .NET class) gets garbage collected (thus releasing the hold on the SharedPtr)
   * All the STL containers (vector, list, etc.) are wrapped by appropriate .NET classes. i.e: 

root.Initialise(false);
Mogre.NameValuePairList list = new Mogre.NameValuePairList();

list["externalWindowHandle"] = winHandle.ToString();
window = root.CreateRenderWindow("", 0, 0, false, list);

   * Heavily used classes are pure .NET classes (ported to C++/CLI) for improved performance (see MOGRE pure .NET classes and OGRE-MOGRE interconnection)
   * Subclassing of OGRE classes by .NET ones (TODO) 

[edit]
Disadvantages

   * Doesn't work in Linux through Mono