Solution If you want/need to compile an Ogre application in C++ CLI (the clr dialect from Microsoft) for whatever reason, then this is possible apparently only if you build your Ogre SDK yourself and, if you use thread support from Boost (other options available, but not considered in my trials), then you must link boost dynamically (shared libraries). Otherwise, C++ CLI built executables will throw a specific exception during initialization. This exception has proven to be generated by the static linking of the boost libthread.. .lib libraries. Using shared libraries/dlls will solve this issue without further headaches.
You can check thisthread and see how one might build Ogre with dynamic boost linkage.
Hi all,
Has anyone successfully used Ogre within a managed C++ application? There are a few known issues with boost, first of all (static linking and /clr do not work together, the application will crash once started).
I built Ogre from scratch using CMake and, as far as my understanding went, I had to also use boost for the Terrain plug-in (which is a requirement for the project I work on). I know the Mogre team tamed these problems, although I'm not sure they did that without excluding boost from the picture.
So, do I have to somehow figure out (which I can't, I'm not a guru) how to build boost to spit out 64 bit dlls produced with a build flag that makes them /clr compatible? And then somehow rebuild Ogre 1.8 and link boost dynamically? And then link the resulting dlls to my tiny test-bed CLI application and see whether it works or not? That's a week of work for me (I am in a world where C++ is known as "that other language that makes a mess, so we use C#.. for web/banking apps" and I can't ask anyone else) and I've already lost a lot of time figuring out what the problem came from in the first place. Any help is hugely appreciated!
[SOLVED] C++-CLI /clr and Ogre 1.8
- teodron
- Halfling
- Posts: 78
- Joined: Fri Jul 22, 2011 11:49 am
- Location: Bucharest, Romania
- x 3
[SOLVED] C++-CLI /clr and Ogre 1.8
Last edited by teodron on Thu Jul 26, 2012 8:51 am, edited 1 time in total.
T
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: C++-CLI /clr and Ogre 1.8
First of all, why do you not just use Mogre? I don't think they would have put all that effort into it if there were an easy way to just use C++ Ogre with C#.
In any case, Boost is not strictly a requirement. What you lose without it is multi-threading support, which for the Terrain component means that certain Terrain processing tasks cannot happen in the background and will block your application until they're done. If you can live with that, you don't need Boost.
You can also try to use POCO or Intel's threadingbuildingblocks instead. They, too, can provide thread support for Ogre, but they are not as intensely tested.
In any case, Boost is not strictly a requirement. What you lose without it is multi-threading support, which for the Terrain component means that certain Terrain processing tasks cannot happen in the background and will block your application until they're done. If you can live with that, you don't need Boost.
You can also try to use POCO or Intel's threadingbuildingblocks instead. They, too, can provide thread support for Ogre, but they are not as intensely tested.
-
- Minaton
- Posts: 933
- Joined: Mon Mar 05, 2012 11:37 am
- Location: Germany
- x 110
Re: C++-CLI /clr and Ogre 1.8
boost is working with CLR here!teodron wrote:Has anyone successfully used Ogre within a managed C++ application? There are a few known issues with boost, first of all (static linking and /clr do not work together, the application will crash once started).
I don't know how you make boost for CLR, but I'm building boost in this ways:teodron wrote:So, do I have to somehow figure out (which I can't, I'm not a guru) how to build boost to spit out 64 bit dlls produced with a build flag that makes them /clr compatible?
32 Bit:
Code: Select all
b2.exe --toolset=msvc-10.0 --build-type=complete stage
Code: Select all
b2.exe --toolset=msvc-10.0 --build-type=complete architecture=x86 address-model=64 stage
- teodron
- Halfling
- Posts: 78
- Joined: Fri Jul 22, 2011 11:49 am
- Location: Bucharest, Romania
- x 3
Re: C++-CLI /clr and Ogre 1.8
It's not my direct decision, it's my employer's. Their logic is based on an assertion: MOgre is behind Ogre 1.8 and will not keep up with it. They want DX11 support, the new Terrain component and to use only a minimal interface with the engine (I did mention that they would like to have nothing to do with C++ whatsoever, but MOgre is too complicated for a non-3D programmer.. hence exposing a minimal set of interfaces that are implemented in C++ CLI and used only in C# projects is their goal). Can't argue with the requirement.CABAListic wrote:First of all, why do you not just use Mogre? I don't think they would have put all that effort into it if there were an easy way to just use C++ Ogre with C#.
If that means having the application freeze while LOD computations take place, then Boost is essential.CABAListic wrote:In any case, Boost is not strictly a requirement. What you lose without it is multi-threading support, which for the Terrain component means that certain Terrain processing tasks cannot happen in the background and will block your application until they're done. If you can live with that, you don't need Boost.
You can also try to use POCO or Intel's threadingbuildingblocks instead. They, too, can provide thread support for Ogre, but they are not as intensely tested.
My Ogre1.8 statically linked to the boost libs works (conceptually) when compiled without the clr flags in a simple c++ program. When the /clr flag is set, the application crashes at runtime inside the initialization stage. The old bjam tool accepted a cxxflags="/clr" flag setting (according tohttp://stackoverflow.com/questions/5670 ... i-problems), and the dll boost clr requirement was stated in various places, one of them being http://marc.info/?l=boost-users&m=123425857320026 .Transporter wrote: boost is working with CLR here!
64 Bit:Code: Select all
b2.exe --toolset=msvc-10.0 --build-type=complete architecture=x86 address-model=64 stage
So, if I build boost this way, will I be able to instantiate an Ogre::Root object in a C++ function, in a project built with the /clr flag in VS100? Will static linking suffice? At the moment, I did everything this way, and it doesn't work for me.
Thanks for the hints!
T
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: C++-CLI /clr and Ogre 1.8
I hate to point this out, but the DX11 support in Ogre 1.8 is far from complete or even stable. You should make sure that whatever you need DX11 support for actually works with that Ogre version, because otherwise you might be wasting time.
- teodron
- Halfling
- Posts: 78
- Joined: Fri Jul 22, 2011 11:49 am
- Location: Bucharest, Romania
- x 3
Re: C++-CLI /clr and Ogre 1.8
That's an observation I've seriously considered when I explained the impact of this decision to my employers . All in all, we require branching in our shaders for (supposedly) increased performance and, perhaps, geometry shaders (for particles and, maybe, water surface effects). It's not clear how reliable the DX11 support is for these things, but their reasoning follows, again, one simple rule: in Ogre 1.9 and 2.0 DX11 support should be there, and if we can provide C# interfaces to other non-expert users, the headache load of upgrading Ogre should be less, since only the C++-CLI implementations must be changed (and we want to keep those at a minimum - for example not exposing many of the otherwise extended Ogre functionality - while MOgre is completely exposing the Ogre architectural design and, again, is revered as being 1 major revision behind).CABAListic wrote:I hate to point this out, but the DX11 support in Ogre 1.8 is far from complete or even stable. You should make sure that whatever you need DX11 support for actually works with that Ogre version, because otherwise you might be wasting time.
T
- Cygon
- Halfling
- Posts: 70
- Joined: Thu Nov 07, 2002 9:36 pm
- Location: Germany
- x 5
- Contact:
Re: C++-CLI /clr and Ogre 1.8
Mogre has a fancy system for auto-generating the C++/CLI code required to make new classes callable from .NET.
You should seriously consider if the relatively minor work required to update Mogre to 1.8.0 isn't far less than the work of writing an entirely new C++/CLI wrapper. There are lots of pitfalls mediating between garbage-collected .NET and C++ even for experienced C++/CLI developers and GC errors are nearly as difficult to track down as threading errors.
You should seriously consider if the relatively minor work required to update Mogre to 1.8.0 isn't far less than the work of writing an entirely new C++/CLI wrapper. There are lots of pitfalls mediating between garbage-collected .NET and C++ even for experienced C++/CLI developers and GC errors are nearly as difficult to track down as threading errors.