Blending OGRE (via MOGRE) into a WPF application

[raygun]

Hi all,

I've posted an article on The Code Project demonstrating OGRE running in the WPF (Windows Presentation Foundation).

Check it out if it sounds useful to you

http://www.codeproject.com/KB/WPF/OgreInTheWpf.aspx

[kingofcrabs]

although wpf can support simple 3d, I think ogre is a better solution.

[Twinsen]

Having drifted off from the gaming\3D community and working in the business side of things these days using technologies such as WPF\Silverlight this is a great excuss to go back to some good ol fashion 3D coding for future projects!.

Awesome work man, I always thought about doing this but never had the time, really nice feature you've made possible

[Mawen]

This is really sweet! I have been wanting a highly capable GUI engine mergable with Ogre for a long time, and I love WPF & MOgre so maybe this will be it!
I look forward to seeing how well it performs and how nicely it plays with Ogre.

[sinbad]

Heh, nice

[raygun]

Thanks for the replies guys

I've been writing a Missile Commander game using Mogre and the WPF, and the OgreImage control seems to be working quite well.

I've also tried it now on more machines with no problems, except my Mac Book running Windows XP in Parallels. If I boot into Windows from Boot camp then it works fine. This is a bit strange because the native Mogre apps run in Paralles quite well.......oh well.
If I maximize the window to full-screen it's a bit slow though. (1960x1200)...so it's not perfect.

What I want to try do is create an app with some particle effects spelling out a company logo behind WPF user controls. That would prove it's worth for the business community who need flashy intro sequences.

[pjcast]

Heh, I just noticed this and think it's pretty cool! I've actually been tasked with some WPF stuff recently (not entirely related to 3D though), and have been looking at the latest SP1 Direct3D integration, and was wondering about how Ogre would perform in such a scenario.

Though, I was thinking of not using Mogre, but just Ogre directly with rendering/scene/logic in C++ - only exporting a few C functions. Not sure if that would give a speed improvement (though, Mogre is pretty darn fast), but would at least cut out one additional dependency/layer for me (I've always had issues in the past while using Mogre and trying to stay updated with current Ogre release).

[pjcast]

Oh, and the Interop DLL project you created, can't you just import the needed Direct3D COM API directly and not use native code for that?

For example, http://www.codeplex.com/WPFMediaKit/Sou ... SetId=7214

[raygun]

Though, I was thinking of not using Mogre, but just Ogre directly with rendering/scene/logic in C++ - only exporting a few C functions. Not sure if that would give a speed improvement (though, Mogre is pretty darn fast), but would at least cut out one additional dependency/layer for me (I've always had issues in the past while using Mogre and trying to stay updated with current Ogre release).

Well not using Mogre would reduce you app's download size quite a bit. (Mogre is quite large)
I suppose it depends on your needs. Mogre is fast and makes it generally very easy to create .NET apps without much fuss, but using Ogre in .NET can be a bit tricky. Also there seems to be a video memory leak (maybe in Mogre/.NET directx object referencing stuff when re-creating the render target).
Also I was having random crashing when resizing the ogre image source. Have a look the OgreImageSource code and process of events that re-creates the render target, I found I had to free some funny stuff off the Viewport before removing it. (was't very intuitive. I needed to look at the Ogre source to find the cause of the problem). Can't remember exactly what it was right now. (be warned though....keyboard bashing was done my me )
I downloaded Mogre's source. This allows you to re-create the Mogre dlls based on the latest Ogre source whenever you need to. It actually was quite easy to get up and compiling.

[raygun]

I just noticed the comment about the interop dll. Thanks for the link.
I'm sure I could just use the interop interface instead. I'll give it a try sometime what I find some time...<sigh>

One of the main reasons I opted for the interop dll was I wasn't sure what problems I'd face and thought it a good idea to have a handy c++ dll ready for all my dodgey code, but for now I don't think 'll need it.

[Mawen]

Has any progress been made on the WPF front lately?

[Mawen]

Ok, I have done some simple benchmarks. I am a newbie with 3D benchmarking, so please keep that in mind, because I don't know what I don't know.

I have two apps, each with a similar scene:

MOgre) MOgre SkeletalAnimation demo, (1000 with 50 rows (and not all of them visible) Robots walking disabled!)
WPF) A modified version of raygun's OgreHead demo app (took out the reflection), using the same or very similar scene as the SkeletalAnimation demo. Note that I don't know how to do "true fullscreen" in WPF, to get exclusive access, if it is even possible.


Test Machine: Vista x64, NVidia 9800 GT, Q6600 @ 2.4Ghz, dual head (1600x1200 and 1920x1200)
(Other test machine I could try, if desired: XP 32, NVidia 6800 (Mobile), Pentium-M @ 1.8Ghz, single head (1920x1200))

Going lower than 1280x1024 seems to hit the Vsync ceiling for WPF, so I start at 1280x1024.

"Full Screen" @ 1280x1024 @85Hz, Windows set to "Look as glitzy as possible"

• MOgre: 227fps
• WPF: 56fps

Windowed @ 1280x1024 @85Hz, Windows set to "Look as glitzy as possible"

• MOgre: 158fps
• WPF: 56fps

Windowed @ 1280x1024 @85Hz, Windows set to "Optimize for Performance"

• MOgre: 164fps
• WPF: 60fps

Windowed @ 1600x1200 @85Hz, Windows set to "Optimize for Performance"

• MOgre: 157fps
• WPF: 44fps

Example of what it looks like in WPF: (Note the checkboxes don't actually do anything -- I just left them in to have something there.) In MOgre, all you see are robots on a back blackground, with MOgre's debug overlay.

WPF-Windowed.jpg

Full Screen @ 1600x1200 @85Hz, Windows set to "Optimize for Performance"

• MOgre: 220fps
• WPF: 44fps
• WPF with 3D view on top half (~50%): 75fps
• WPF with 3D view on left half (~50%): 73fps
• WPF with 3D view on top-left half (~25%): 97fps (probably at vsync ceiling)
• WPF with 1 robot: 48fps !!
• WPF with 500 robots: 48fps !!
• MOgre with 500 robots: 620fps
• MOgre with 1 robot: 3820fps (yes, that's quite a bit bigger than any other test.)
• WPF: 44fps - Disabled the border with a background gradient didn't seem to significantly improve the framerate (no real improvement)
• WPF: 47.5fps - Made OgreImage the only content of the WPF window, (slight improvement)
• WPF: 39fps - Added 100 30x30 buttons in random locations.
• WPF: 14fps - Added 1000 30x30 buttons in random locations.

Full Screen @ 1600x1200 @85Hz, Windows set to "Optimize for Performance", Robots walking on

• MOgre: 60fps
• WPF: 30fps
• WPF with 3D view on top-left half (~25%): 45fps
• MOgre at 800x600: 61fps
• WPF: 14fps - Added 1000 30x30 buttons in random locations. (Same as robots walking off!)
• WPF: 11fps - Added 1000 30x30 buttons in random locations with random opacity.

Windowed example of 3D view only in the top left corner:

WPF-Windowed-25percent.jpg

Fullscreen WPF example of 1000 transparent buttons:

WPF-FullScreen-1000Buttons.jpg

Conclusions:
===========

• WPF frame rate seems quite dependent upon resolution of the 3D Ogre view.
• I don't really know what I'm doing... maybe optimizations or better approaches are possible somewhere.
• Offtopic: I also want to look at Moonlight as a (more portable and flexible) alternative.
• Have thoughts? Ideas? Please share!

Notes:
=======

• Maybe I should test it with some fancy WPF stuff going on to see how that affects the frame rate. I have an animated moving green rectangle (shown in top left) but didn't do anything beyond that.
• Having my Vista Sidebar (with a bunch of gadgets in it) render on top of the WPF window causes a big frame drop (~55 to ~35 in one of my tests), but clicking on the WPF window to move it to the front immediately boosts the frame rate back to 55.
• Clicking a window on my 2nd monitor brings the windows taskbar and vista sidebar to the front, which may not be desired.
• Going below 1280x1024 doesn't seem valuable since WPF seems to force VSync, which ceilings my fps count around the refresh rate (or a bit higher, which I thought was weird... maybe my calculations are flawed. I had to do my own stats calculation in the WPF app...)
  

  Code: Select all

          protected void UpdateStats()
          {
              string currFps = "Current FPS: ";
              string worstFps = "Total timer: "; 
  
              try 
              {
                  OverlayElement guiCurr = OverlayManager.Singleton.GetOverlayElement("Core/CurrFps");
                  OverlayElement guiWorst = OverlayManager.Singleton.GetOverlayElement("Core/WorstFps");
  
                  long statsUpdateTicks;
                  HiPerfTimer.QueryPerformanceCounter(out statsUpdateTicks);
  
                  if (lastStatsUpdate != 0)
                  {
                      double statsTimeLapse = (double)(statsUpdateTicks - lastStatsUpdate) / (double)perfFreq; 
                      guiCurr.Caption = currFps + (framecount / statsTimeLapse).ToString();
                      guiWorst.Caption = worstFps + framecount + " " + statsTimeLapse.ToString();
                  }
                  lastStatsUpdate = statsUpdateTicks;
              }
              catch {}
              framecount = 0;
          }
  

Questions:
===========

Fullscreen
-----------
Is there a better way to do a "fullscreen" app in WPF? I'm just using:

this.WindowState = WindowState.Normal;
this.WindowStyle = WindowStyle.None;
this.ResizeMode = ResizeMode.NoResize;
this.WindowState = WindowState.Maximized;
this.Topmost = true;

[pjcast]

Well, while the framerates are substantially lower, at least there still within reason. But, yeah, I've noticed WPF + DIrect3D to be a lot slower than using all native - not sure if there are any optimizations one can make (outside of MS) as the bottleneck seems to be the surface copy.

[Mawen]

I've been watching some PDC videos (namely http://channel9.msdn.com/pdc2008/PC07/, at 58:20) and discovered that hardware acceleration may be possible for interop: See http://msdn.microsoft.com/en-us/library/cc656910.aspx for the hw accel cases supported for Vista & XP.

I am going to try to recompile Ogre's D3D driver to use Direct3DCreate9Ex instead of Direct3DCreate9 to see if that will help on Vista. (I'm working on it but I am running into problems with my newly built OgreMain.dll and RenderSystem_Direct3D9.dll... maybe I need to recompile all of Ogre and MOgre.) For XP SP3, it looks like you can get hw accel if you use lockable textures (D3DFMT_X8R8G8B8 or D3DFMT_A8R8G8B8 ... any idea on the likely place to turn on lockable textures?? HardwareBuffer or Texture in the D3D render system project?).

[Mawen]

Update: I'm really hoping I can see a dramatic improvements to my benchmarks by getting the hardware acceleration working. I don't like seeing the framerate crash when going to 1920x1200 and if it didn't do that, I think I might be happy enough with WPF to include it in my project(s).

I'm stuck at the moment but will hopefully figure it out sometime this week.... I can recompile MOGRE+OGRE but the resulting DLLs seem to work but show no image with raygun's WPF DLL so I have to figure out what went wrong. Raygun, if you get a chance and are running Vista, maybe you can beat me to it by recompiling your build with this change to "\Mogre\ogrenew\RenderSystems\Direct3D9\src\OgreD3D9RenderSystem.cpp", line 85 (if you are on Vista. If you are on XP, you can try creating locked textures, which I don't know how to do yet.)

Code: Select all

		
     		// Create our Direct3D object
		Direct3DCreate9Ex(D3D_SDK_VERSION, (IDirect3D9Ex**) &mpD3D); // Umm.. this cast may not be valid
		if( NULL == mpD3D)
                {
		   if( NULL == (mpD3D = Direct3DCreate9(D3D_SDK_VERSION)) ) // Fallback for non-Vista
                   {
			OGRE_EXCEPT( Exception::ERR_INTERNAL_ERROR, "Failed to create Direct3D9 object", "D3D9RenderSystem::D3D9RenderSystem" );
                   }
                }

In the meantime, people may also be interested in this quick demo showing WPF on top of and underneath Direct3D content:

http://channel9.msdn.com/pdc2008/PC46/ at 38:00.

[Mawen]

Success! I appear to have eliminated the resolution-correlating (software mode) bottleneck (for Vista / WDDM, at least.) With my old RenderSystem_Direct3D9.dll I get around ~40fps at 1920x1200 and with my new one (ported to 9Ex), I get ~97fps!! (which I think is hitting my max due to vsync or WPF trying to match my framerate.)


DirectX 3D 9Ex doesn't support Managed pools, so I had to turn them all off. I did a search and replace for D3DPOOL_MANAGED and replaced it with D3DPOOL_DEFAULT. I don't really know what the implications of this are, but apparently D3D9Ex manages pools on its own somehow. For more info, see this very enlightening thread:

http://www.eggheadcafe.com/software/asp ... dpool.aspx

I also set #define OGRE_D3D_MANAGE_BUFFERS 0, and this helped a bit with vertex buffers, but I still needed to do the search and replace to get normal textures working without throwing an "invalid call" exception.


....Next step: figuring out how to accomplish the same thing in WinXP, since Direct3D 9Ex is Vista-only. (Apparently, you have to use a locking texture in XP. It isn't clear to me from the MSDN docs whether locking textures works on just XP, or both XP and Vista, so we will have to see!)

[Mawen]

....Next step: figuring out how to accomplish the same thing in WinXP, since Direct3D 9Ex is Vista-only. (Apparently, you have to use a locking texture in XP. It isn't clear to me from the MSDN docs whether locking textures works on just XP, or both XP and Vista, so we will have to see!)

Ok! So I almost gave up on figuring out the deal on lockable textures but then hit the google jackpot. I found out the following things:

• As said before, the optimized approach for XP (or XDDM) requires lockable surfaces.
• Ogre creates a TU_RENDERTARGET Texture with D3DUSAGE_RENDERTARGET.
• A D3D Texture with D3DUSAGE_RENDERTARGET is not lockable. (See http://www.gamedev.net/community/forums ... _id=325525 for a discusssion).
• I tried replacing TU_RENDERTARGET with other options, namely the TU_DYNAMIC* ones, and none worked (as expected).
• The way to go looks like to use mpDev->CreateRenderTarget instead of D3DXCreateTexture. This returns a IDirect3DSurface9 instead of IDirect3DTexture9, so this is not supported by Ogre's D3D9Texture! Doh...

Proposed solution for integrating this into Ogre:

• Add TU_RENDERTARGET_LOCKABLE to the TU_ enum
• In D3D9Texture::createInternalResourcesImpl, detect this and execute a method similar to D3D9Texture::_createNormTex() that instead uses "hr = mpDev->CreateRenderTarget(" instead of "hr = D3DXCreateTexture(".
• Implement MOGRE's TexturePtr::GetBuffer().GetRenderTarget() in Ogre, which is needed by raygun's WPF-OgreImage.

OGRE experts: How does this sound?

Unfortunately, it looks like this requires some D3D & OGRE expertise and potentially some modifications to RenderTarget and HardwarePixelBuffer the Ogre/MOgre codebase, and I am not familiar with how to create this modified createNormTex method, or what else might need to be changed. If I need a digression, I may take a quick stab at it, but by the time my game gets published, there may not be anyone left using XP (fingers crossed that Windows 7 will actually be liked ), so I don't know if it's worth it for me to spend much time at it.

[jmix90]

What is the purpose of the interop dll ?

I don't understand why we do not use directly the D3DImage ?

Thx by advance for any answer !

[raygun]

The inteop dll is used to access the status of the directX device that I couldn't get via Mogre.
I'm sure I could have used managed directX but I wasn't sure of the dependancies plus I couldn't get to work via ManagedDX.

Sorry, but what do you mean ? "use directly the D3DImage" ?

[jmix90]

I don't understand why we do not use directly the D3DImage ?

My mistake....

Thx for your answer !

[jmix90]

Hello,

Sorry for taking your time, but It's tell on your Codeproject's page's comments that we can use Mogre for getting an IntPrt for the D3DDevice :

I would like to know how we can use it to do a TestCooperativeLevel on the .NET side.... I tried a lot of things and I didn't manage to get this works....


Any clues ?

Thx by advance...

[Lennartos]

Any news on this?
Especially on the XP speed issue.

I was just looking into the same thing as i stumbled across the Code Project.
I tried it out, and it was brilliant.
The combination of quick 3D and a fully featured - and quickly expandable - 2D GUI is colossal.

However, during my investigation on the slowdown i came to exactly the same conclusion as Mawen
Namely that we require a locked rendertarget, but rendertargets are inherently unlockable.
(also seems 16 bit desktop also is a killer)
As i see it a Render To Texture would be needed, and i am unsure on how to do that. (tried TU_DYNAMIC and others , but didnt work).

I really think this should get some more attention,as this has the potential to become a "normal" MOGRE usage pattern, opening up endless possibilities for Game and non-Game development.

[jmix90]

I have tested it with the last version of Ogre 1.6.4 but I didn't suceed to use an another type of texture...

You are right, it is very nice to blend WPF and mogre : http://www.ogre3d.org/forums/viewtopic.php?f=11&t=51516

[Lennartos]

Any ideas on why we cant render to anything else than a rendertarget?

[Mawen]

There's no news from me yet. I'm not exactly sure yet how important XP is to me or whether I will have time to try making the changes. I am also a little scared to take a stab at messing with Ogre's textures without getting a design review from someone on the Ogre team.