OGRE Wiki
Support and community documentation for Ogre3D
Ogre Forums
ogre3d.org
Log in
Username:
Password:
CapsLock is on.
Remember me (for 1 year)
Log in
Home
Tutorials
Tutorials Home
Basic Tutorials
Intermediate Tutorials
Mad Marx Tutorials
In Depth Tutorials
Older Tutorials
External Tutorials
Cookbook
Cookbook Home
CodeBank
Snippets
Experiences
Ogre Articles
Libraries
Libraries Home
Alternative Languages
Assembling A Toolset
Development Tools
OGRE Libraries
List of Libraries
Tools
Tools Home
DCC Tools
DCC Tutorials
DCC Articles
DCC Resources
Assembling a production pipeline
Development
Development Home
Roadmap
Building Ogre
Installing the Ogre SDK
Setting Up An Application
Ogre Wiki Tutorial Framework
Frequently Asked Questions
Google Summer Of Code
Help Requested
Ogre Core Articles
Community
Community Home
Projects Using Ogre
Recommended Reading
Contractors
Wiki
Immediate Wiki Tasklist
Wiki Ideas
Wiki Guidelines
Article Writing Guidelines
Wiki Styles
Wiki Page Tracker
Ogre Wiki Help
Ogre Wiki Help Overview
Help - Basic Syntax
Help - Images
Help - Pages and Structures
Help - Wiki Plugins
Toolbox
Freetags
Categories
List Pages
Structures
Trackers
Statistics
Rankings
List Galleries
Ogre Lexicon
Comments
History: MOGRE Introduction
View page
Source of version: 11
(current)
!!What is MOGRE? __MOGRE (Managed OGRE)__ is an advanced .NET wrapper for OGRE, [http://sourceforge.net/projects/mogre|hosted on sourceforge]. The "glue" code between C++ and .NET is developed using C++/CLI, which offers great flexibility and low-level control of how the wrapping should work. MOGRE goes beyond a plain wrapper; the OGRE classes are integrated into the .NET framework seamlessly (see ((OGRE-MOGRE interconnection))). 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. {maketoc showhide="y"} !!!Downfalls of using a ported project * Because a port requires the manual re-writing of code, ** There is an increased chance of bugs being introduced to what started as already-stable. ** It takes a long time to complete anything. ** 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 [http://www.ogre3d.org/wiki/index.php/Paging_Scene_Manager|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 !!!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. ** This means less chance of bugs being introduced ** 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))) --- Alias: (alias(Mogre overview)) Alias: (alias(MOGRE_Introduction))
Search by Tags
Search Wiki by Freetags
Latest Changes
Minimal Ogre Collision
Artifex Terra
OpenMB
Advanced Mogre Framework
MogreSocks
Critter AI
Mogre Add-ons
MOGRE
Mogre MyGUI wrapper
MOGRE Editable Terrain Manager
...more
Search
Find
Advanced
Search Help
Online Users
21 online users