Mogre + WPF


19-11-2009 11:34:29

Hi all,

I've been porting my code to WPF (don't ask), and I'd obviously like Mogre to come along. I have a custom OgrePanel class (deriving from System.Windows.Forms.Panel), which is used as a 3D viewing panel and has some tools associated with it.

There seem to be 2 ways to go about this:

1. Host the OgrePanel in a WPF window using a WindowsFormsHost object (in WindowsFormsIntegration.dll).

I have this working, and it appears to be working fine. I should perhaps point out that I was not able to do this in xaml, due to my assembly not being 'strongly named'. I don't really know what that means, but it has to do with the namespaces available to the CLR not being available as X(A)ML namespaces. Anyway, it means you lose the ability to design your window entirely visually (using the Toolbox), which is a pity but not really dramatic in my case.

I'm under the impression that, to compile a strongly named assembly (OgrePanel.dll), all the assemblies it references (this includes Mogre.dll) also have to be strongly named. I think this requires Mogre to be recompiled from source. This is talked about in this post (in a different context, though):

It seems like it's quite straightforward to recompile Mogre as a strongly named assembly (especially see the comment made by Marioko in the post above). I've succeeded in compiling Mogre from source (see this post: If someone (Marioko?) can offer some clear instructions on how to do this, I'm quite willing to give it a try and let you know how that goes. It's quite a lengthy process compiling Mogre from source, so I'd prefer not to have to try 10 times before getting it right.

2. Making a 'true' WPF Mogre control

This is discussed in this entry on codeproject (Mogre 1.4):

I can't really follow all the details, but it comes down to having a OgreImage object, based on WPF ImageSource and D3DImage (which appears to suggest it might be limited to DirectX rendering). The core part of this is written in C++, which scared me right off, so I haven't tried this out. Also, the author himself (a good fellow named Leslie Godwin) doesn't seem to be sure this is the 'proper' way of doing this.

So my question would be: what do you guys think is the best way to proceed? I have a working solution, so I could just leave it at that and concentrate on the more important tasks at hand. On the other hand, it seems like A Bad (and Unpractical) Thing to have your WPF application hosting WinForms controls, so eventually something will have to come along to address this issue. Is there any such a thing in any pipeline?

Any ideas, anecdotes or suggestions highly appreciated!

Roy Berube

28-11-2009 04:50:09

I was toying around with wpf in Mogre a while back and came to the conclusion that performance will be an issue when using wpf. Separate threads are needed for rendering the gui and reading input if I recall correctly. The performance for a real time engine just isn't there.

I hope you find a way to get an efficient wpf implementation working.


01-12-2009 14:35:56

Hi Roy,

Thanks for your input. Performance indeed seems to be a major concern in this. I'm nowhere near good enough at WPF (nor Mogre, actually) to even attempt to implement this, let alone implement it efficiently. I'm always willing to help test (performance- or otherwise) a proposed solution, though.

So, until someone more experienced comes along, I guess we'll have to make do with the WFH-hosted solution. Which is fine by me, except for 1 small but annoying detail (see screenshot below): I can't seem to 'ClipToBounds' the WFH-control (which has a fixed size equal to the Ogre render window size). This doesn't really seem to be Ogre-related, as I have the same problem with other hosted controls (not with WPF-controls, though). So pardon me for going slightly off-topic, but if anybody knows how to fix this, please let us know.