Ogre with wpf client

hi all,

I am trying to embed the ogre in to the wpf client(Not MOGRE). What i want to do is wrap all the functionality in a COM dll and call the functions through WPF. I am currently working with Basic tutorial 1 for the sake of testing. My idea is to get the backbuffer and send it to the wpf app through interface and somehow render it there.... But i don't know how to do it.. I am new to OGRE but have a knowledge about DirectX. I don't want to use MOGRE as it is in a beta stage:(. So i have to work with OGRE.

Please help me in achieving this.....

Thanks in advance....

I don't want to use MOGRE as it is in a beta stage:(. So i have to work with OGRE.
The beta-tag shouldn't prevent you from using Mogre. The current release is stable and only a lack of feedback prevents mstoyke from removing the beta status.

If you don't need any unwrapped Ogre plugins, you should definitly try Mogre before wrapping anything yourself (and even then, wrapping the plugin should be easier to accomplish than wrapping Ogre funcionality).

Thanks tafkag....

that is a real breather for me.
Can any body from mods shed some more light on this.........................

Have you seen this article? http://www.codeproject.com/KB/WPF/OgreInTheWpf.aspx

Another link: http://www.ogre3d.org/forums/viewtopic.php?f=11&t=44263&p=323210#p323210

Have you seen this article? http://www.codeproject.com/KB/WPF/OgreInTheWpf.aspx
Thanks for this link, very interesting! This is for Ogre 1.4.8 and Mogre 1.4.8 but is it still actual?

I recompiled for 1.6.4, I believe, and I am now working with 1.7.1 as my signature indicates (although I have modified the OgreInTheWpf).

I think you should be able to recompile it against a new Ogre/Mogre. Can you do this or were you hoping for a binary?

One thing that I hope finds an official solution is hardware rendering, since software-only rendering is is a bottleneck at non-small resolutions as I discussed in the benchmark thread (my nick there is Mawen). I ported Ogre's D3D9 to 9Ex to get a huge perf boost but then lost my source to 9Ex. I may try the new D3D 11 (not sure what the status of that is) or else reimplement 9Ex (it was only a few lines of code that needed changing in Ogre's D3D9.)

No, I was not waiting for a binary upload I think I can do it on my own but I was wondering if it still works because WPF and Mogre changed a bit since Ogre 1.4.8 I think (for example .NET 4).

I'm not sure about D3D11 but in CMake you can choose to compile D3D11 as rendersystem. It looks as if there would be already Ogre support...

Welcome ppontheweb to the Mogre community!
Nice to see that someone else want to try to combine Ogre with WPF

I didn't see much people who tried it. There are still problems as I read. Most important problem is the transparency, because Mogre (also C++ Ogre ??) and WPF have no common access to the image buffer (or somehow similar). The result is an annoying flickr.
Well, details I can tell you, but I searched for some links to the related topic. Maye it helps you.

Blending OGRE (via MOGRE) into a WPF application
http://www.ogre3d.org/forums/viewtopic.php?f=11&t=44263

MOGRE +WPF
viewtopic.php?f=8&t=11913

Prototype steps of GUI development
http://www.ogre3d.org/tikiwiki/Prototyp ... evelopment

Use a screenshot of a WPF visual as a texture in Mogre
http://www.codeproject.com/Articles/597 ... -in-M.aspx

Deciding on MOgre ... about WPF, alternative C# engines, etc
viewtopic.php?t=13316


Mogre in beta status?
It seems to be stable, although it's a problem for some people that not all add-ons work with the current version Mogre 1.7, because the add-on maintainers retired. If you like, you can just try out Mogre. By the way - some days/weeks ago a "big" commercial game was released (Dungeons), which bases on Mogre. I suppose they would not had do that if Mogre is unstable.
Also Mogre 1.6 is stable and still powerful.

Alternatively I want to refer you to AXIOM. It's a port from Ogre to C#. As I read it has not as many features as Ogre/Mogre, but is pure .NET code (which can have some advantages). Maybe with AXIOM is more friendly in cooperation with WPF? I don't know, but it would be nice when you report about your Ogre/Mogre/AXIOM to WPF integration after you have done some research and tests.


I recompiled for 1.6.4
It would be nice when you publish your updated source code.
Maybe you write an message to the owner of the code project article to offer the download on this "official" place. I suppose this is a starting point for many people and it's good do have updated versions on the main publishing place. Otherwise the people doesn't know that it exists (usless they find it somewhere else by random).


Meharin, in your signature you write you use WPF.
It would be nice if you write some experiences about your WPF+D3DImage to Mogre integration.

I didn't see much people who tried it. There are still problems as I read. Most important problem is the transparency, because Mogre (also C++ Ogre ??) and WPF have no common access to the image buffer (or somehow similar). The result is an annoying flickr.

I was unaware of transparency problems and I thought I read everything. (Are you sure you aren't thinking WinForms? One of your links mentions someone switching from WinForms to WPF and it solved their transparency issue.) The only flicker problem I heard of was Mathieu Frenette of Simbioz who was trying to do something with multiple viewports at once I think ([Edit:]Here is his comment http://www.codeproject.com/KB/WPF/OgreInTheWpf.aspx?msg=3404546#xx3404546xx).

Transparency for me seemed to work fine. I had a transparent Mogre scene sandwiched by transparent WPF controls. I had partially transparent buttons on top, a Mogre scene in the middle with a transparent background, and a WPF background. I didn't notice any obvious flickering. I had these screenshots in the benchmark thread in the ogre forum but it looks like they are broken now .

WPF has the concept of D3DImage (a Microsoft-provided class) that lets you display a D3D texture as a first class WPF image. Therefore there is no airspace issue like there was in WinForms. (Flickering might happen if the Mogre rendering to texture happens in a separate thread than the WPF render, but WPF lets you inject into its render loop so I don't see why this might be a problem, and I plan to try multiple Ogre viewports and Mogre instances (via multiple D3DImages) soon.)


Use a screenshot of a WPF visual as a texture in Mogre
http://www.codeproject.com/Articles/597 ... -in-M.aspx


This approach is new to me! I wonder how the practicality/performance of OgreInWpf compares to WpfInOgre.


Maybe with AXIOM is more friendly in cooperation with WPF? I don't know, but it would be nice when you report about your Ogre/Mogre/AXIOM to WPF integration after you have done some research and tests.


I see no reason why AXIOM would work better than Mogre. Raygun's OgreInWpf already bridges to Mogre. Basically, if you can get something into a D3D texture, WPF can draw it.
(Not to say Axiom may not have it's advantages. If something blows up in Ogre on the C++, it's hard to debug, in Visual C# Express at least. Thank goodness for log files.)

[Edit: Mathieu Frenette told me AXIOM was more stable for him. I would like to figure out why this is.]

I recompiled for 1.6.4
It would be nice when you publish your updated source code.
Maybe you write an message to the owner of the code project article to offer the download on this "official" place. I suppose this is a starting point for many people and it's good do have updated versions on the main publishing place. Otherwise the people doesn't know that it exists (usless they find it somewhere else by random).

Meharin, in your signature you write you use WPF.
It would be nice if you write some experiences about your WPF+D3DImage to Mogre integration.

I have already shared all my experiences in the forum links you mention. (My nick in the Ogre forum is Mawen.)
I don't recall making any code changes to get OgreInWpf working for 1.6.4 or 1.7.1.

Since multiple people seem to be interested in this, perhaps I will try to package what I have and put it on a repository somewhere.

Idealistic todo list:
- Put a modified version of Raygun's OgreInWpf up as an open source project (I'm thinking MIT license)
- Revamp it a little bit to allow for multiple D3DImage instances using a single Root (I did this, as did the person above I mentioned who was trying multiple views and getting flickering -- me, I get a few successful frames then black screen of death, have to figure out what's going on.)
- Performance demos and tests to determine overall feasibility.
- Input support: MOIS? Picking?

It looks like multiple people are still interested in this, so maybe it's worth it for me pursuing this to get more eyes on it.

As a teaser, (and since my other thread's screenshots are gone), here is a screenshot that shows the transparency I described working with WPF and Mogre:

The blue/black gradient is WPF. The Mogre is drawn inside the thick blue border and you can see there is semi-transparent WPF stuff on top. (The WPF window itself is semi-transparent -- you can see my web-browser underneath the title bar.)



(If you're wondering, the graph in the top right is DDD: http://dynamicdatadisplay.codeplex.com)

Ok, I put together the beginnings of a little package that is minimally based on OgreInTheWpf, with some of my own changes and additions:

Feel free to check it out at https://bitbucket.org/JaredThirsk/mogreinwpf/downloads!
(Instructions: Unzip the dependencies zip (separate download) to the source folder, open the solution pick a startup project and run!)


(Note: in this screenshot, Ogre is rendering 2000+ FPS, but WPF isn't drawing as fast. Expand the WPF Stats expander to see the WPF framerate.)

TODO update: I am trying to catch up to where Mathieu got to in this comment, with multiple viewports, and then 9Ex: http://www.codeproject.com/KB/WPF/OgreInTheWpf.aspx?msg=3404546#xx3404546xx

I sure am talking to myself a lot here

Update:

1. I recreated my Ogre Direct3D 9Ex plugin and got the big performance boost again (no software render to texture bottleneck). I put the code up on a new site here: https://bitbucket.org/JaredThirsk/ogre-d3d9ex so I don't lose it again and others can try it. It might be nice (least amount of work to maybe integrate 9Ex into the official Ogre branch) to make 9Ex an option within the 9 plugin, with an optional fallback to 9. Maybe I will do this at some point. For now it is an #ifdef on D3D9EX, and if you rename it after you build it, it can live side by side with the standard D3D9 plugin.[/*:m]
   
2. I seem to be able to do multiple Ogre viewports without any problem. (I would't expect there to be one.)[/*:m]
   
3. I have major problems with multiple MogreImages within the same process (different windows). I think Mathieu had more success somehow.[/*:m]
   
4. Multiple MogreImages in multiple processes seems fine. I had 4 windows running at 50+ FPS. (WPF normally caps framerate at 60FPS on my machine.)[/*:m][/list:u]
   
   Here's a screenshot showing what I think is a real WPF FPS count on a massive (almost 1920x1200) resolution:
   
   (Note: WPF normally renders at 60FPS max (on my machine, for vsync presumably), unless you 'poke' it. I poked it by moving the mouse around to get a relatively astronomical WPF refresh rate of 140FPS. UPDATE: I pretty sure WPF doesn't render at 140 frames and only fires CompositionTarget.Rendering faster when I poke it. For the true framerate I should run the wpf perforator on it.) Without 9Ex, this framerate is not possible (I get around 33FPS, peaking around and 52 if I move the mouse frantically (which to me is a surprisingly high boost).)

Ok, one more post. For kicks I tried a fully transparent WPF window with nothing but an ogre head:



Sweet!

[Update: Looks like there's no way to get good performance with dynamically transparent windows like this. If you turn on "AllowsTransparency" in a WPF window, it looks like there is some software rendering going on here, so you will likely hit the same bottleneck that is seen in D3D9, for large resolutions.]

Transparency for me seemed to work fine. [...] I had these screenshots in the benchmark thread in the ogre forum but it looks like they are broken now .
Very nice.
It's a pitty that I can't see your screenshot. In our Ogre forums it's possible to attach/include images (or other small files). So this could be an alternative to image hosters. .... now I see it in a newer post.


Since multiple people seem to be interested in this, perhaps I will try to package what I have and put it on a repository somewhere.
This would be great.

Input support: MOIS? Picking?
What is Picking? An input library?

I sure am talking to myself a lot here
I'm sorry that I didn't read/answered more early. But as you see, I'm still following you. Also I'm shure, that your publications here are useful for others, even when they doesn't post here. (Even in the future some people will find your forum topic very usefu.)
I have different activity periods. Sometimes I do Ogre public work for many hours each day. Other times I don't like to do anything and don't want to force myself. I did this in the past, but this is not good for my long-term motivation.

What is 9Ex?
Extended DirectX 9 ??

Thanks for sharing all your knowledge and experiences.
Maybe I should create a wiki page about Mogre and WPF to collect all useful links and information.

Since multiple people seem to be interested in this, perhaps I will try to package what I have and put it on a repository somewhere.
This would be great.

Virtually everything I have should now be in these two projects: https://bitbucket.org/JaredThirsk/mogreinwpf, https://bitbucket.org/JaredThirsk/ogre-d3d9ex


Input support: MOIS? Picking?
What is Picking? An input library?


By 3D Picking I meant selecting 3D objects with the mouse. My demo app now has this, although I'm not sure how accurate my implementation is.


I sure am talking to myself a lot here
I'm sorry that I didn't read/answered more early. But as you see, I'm still following you. Also I'm shure, that your publications here are useful for others, even when they doesn't post here. (Even in the future some people will find your forum topic very usefu.)
I have different activity periods. Sometimes I do Ogre public work for many hours each day. Other times I don't like to do anything and don't want to force myself. I did this in the past, but this is not good for my long-term motivation.


Yeah I know there are always lurkers, or people who read it months later.


What is 9Ex?
Extended DirectX 9 ??


From wikipedia:

An extension only available in Windows Vista, called Direct3D 9Ex (previously versioned 9.0L), allows the use of the advantages offered by Windows Vista's Windows Display Driver Model (WDDM) and is used for Windows Aero.[7] D3D 9Ex, in conjunction with DirectX 9 class WDDM drivers allows graphics memory to be virtualized and paged out to system memory, allows graphics operations to be interrupted and scheduled and allow DirectX surfaces to be shared across processes.



Thanks for sharing all your knowledge and experiences.
Maybe I should create a wiki page about Mogre and WPF to collect all useful links and information.

That's an idea. I tried to start wikis (only one page) on both my open source projects listed above. If you do start one, feel free to steal anything you like. I could add a link on my wikis to any new wiki.

By 3D Picking I meant selecting 3D objects with the mouse.
Nice, I also want to embedd something similar to my application. So I can learn from your code.

That's an idea. I tried to start wikis (only one page) on both my open source projects listed above. If you do start one, feel free to steal anything you like. I could add a link on my wikis to any new wiki.
I didn't recognize that you created wiki pages. Good work!
Now we should decide where to place the documentation. Either inside of the Ogre wiki or keep it in the external repository wikis.
My personal opinion is: For small documentations (just one page) the Ogre wiki is a good place and for huge, complex projects an external wiki makes sense. The advantage of much information in the Ogre wiki is, that we have most information on one common place and it's more easy for people to find it.
So if you agree, we could move the documentation to the Ogre wiki. To have redundant wikis isn't very good, because of needed extra work for synchronization. Otherwise it could happen that people are confused or use the outdated documentation.
This is my proposal. But the choice is yours.

By 3D Picking I meant selecting 3D objects with the mouse.
Nice, I also want to embedd something similar to my application. So I can learn from your code.


(I learned from someone else's code somewhere. Yay for wikis.)
You should try the sample app first. It doesn't seem very accurate to me so there may be bugs (And/or maybe it is working off of huge bounding boxes.)


I didn't recognize that you created wiki pages. Good work!
Now we should decide where to place the documentation. Either inside of the Ogre wiki or keep it in the external repository wikis.
My personal opinion is: For small documentations (just one page) the Ogre wiki is a good place and for huge, complex projects an external wiki makes sense. The advantage of much information in the Ogre wiki is, that we have most information on one common place and it's more easy for people to find it.
So if you agree, we could move the documentation to the Ogre wiki. To have redundant wikis isn't very good, because of needed extra work for synchronization. Otherwise it could happen that people are confused or use the outdated documentation.
This is my proposal. But the choice is yours.

I am up for moving to ogre wiki. Some of my wiki relates to the project -- I think it may make sense for that to stay with the project. (I'm not sure what percentage.)

It doesn't seem very accurate to me so there may be bugs (And/or maybe it is working off of huge bounding boxes.)
If you use Rays for object detection, then you should keep in mind that Ogre rays only detect bounding boxes (AABB) of objects.
For more accurate ray hits have a look to this wiki page:
Raycasting to the polygon level - Mogre
In the case of overlapping AABBs you should consider to check all RayQueryResults for polygon distance and take the shortest one.

For more accurate ray hits have a look to this wiki page:
Raycasting to the polygon level - Mogre


Ooh sweet!! I needed that, thanks! I added this to my MogreInWpf project and it seems to work great. Pixel perfect as far as I can tell (note: I didn't look into the animated meshes issue.)

I also massaged the API a bit:

RaySceneQuery raySceneQuery = sceneManager.CreateRayQuery(camera1.GetCameraToViewportRay(x, y), SceneManager.WORLD_GEOMETRY_TYPE_MASK);
Entity closestEntity = raySceneQuery.RaycastToClosestEntityMeshTriangle(ref /* Vector3 */ closestPoint, ref /* Vector3 */ hitNormal /*, bool calculateNormal = true by default */);

My game has a client-side physics engine so I wonder if I should wonder if it's better for performance to use that instead for raycasting.

Hi There,

Im truely fascinated using mogre/ogre and Wpf together.

Because I'm quite new to Ogre this maybe not a question related to this Project... So forgive me if thats the case.

I'm developing an application which should run on winxp,vista and win7. I'm experiencing an Antialiasing problem when running the OgreinWpf-Version with the normal direct3d_rendersystem-plugin. The Result shows aliasing like hell.

Let me begin with the version if dx10 or 11 is available:

Im Creating the RenderTarget with AA-Options (just available for the direct3dex device, so i use the d3dex-plugin)

_texture = TextureManager.Singleton.CreateManual(
"OgreImageSource RenderTarget",
ResourceGroupManager.DEFAULT_RESOURCE_GROUP_NAME,
TextureType.TEX_TYPE_2D,
(uint)ViewportSize.Width, (uint)ViewportSize.Height,
0, Mogre.PixelFormat.PF_A8R8G8B8,
(int)TextureUsage.TU_RENDERTARGET,
null,false,16,"Quality");

And everthing is fine without Aliasing.

But when im running under Xp, I have to switch to TextureCreation without AA...

_texture = TextureManager.Singleton.CreateManual(
"OgreImageSource RenderTarget",
ResourceGroupManager.DEFAULT_RESOURCE_GROUP_NAME,
TextureType.TEX_TYPE_2D,
(uint)ViewportSize.Width, (uint)ViewportSize.Height,
0, Mogre.PixelFormat.PF_A8R8G8B8,
(int)TextureUsage.TU_RENDERTARGET,
null, false);

My Question is now, is there a possibility to get a final render result without Aliasing? Maybe through Windows/RenderSystem-Settings?

I allready tried all options for the Created Window i could find... But nothing works.

Is there a possible solution for this Problem?

Thx in Advance

Hmm, honestly I don't know much about Direct3D or anti-aliasing.

Maybe this is one of the things you tried, but have you tried the FSAA option mentioned here?: (I'm not sure it would do anything for rendering to a texture.)
http://www.ogre3d.org/docs/api/html/cla ... 6f6b672620

BTW, are you seeing reduced performance using the D3D9 plugin (which is only one that works on Windows XP) and are you ok with that? I'd still like to see OgreInWpf work fast on Direct3D 9 as well but I'm not sure how much work it is.

Another random idea that probably won't help is that people complain WPF antialiases (blurs) their images when resizing them. Maybe if you can get WPF to resize the image a little, WPF will antialias it. http://stackoverflow.com/questions/1738 ... -wpf-image

My game has a client-side physics engine so I wonder if I should wonder if it's better for performance to use that instead for raycasting.
It needs some effort, but the best way is to implement both ways and compare the performance result.

As I read, the "Bullet" Physics Engine has a high performance on RayQueries.(I don't know how trustworthy this statement was.)
Unfortunately I don't know if this query is on BoundingBox or poligon level.
Additional I didn't see a .NET wrapper here in the form.

For high performance collision detection you can try to use the "SOLID" library.
It's used in robotic research and I suppose very stable.
With the "Callisto" visualisation and collision checking library you can use the SOLID library by Ogre.
Well, for Mogre you would need an extra wrapper. I just wanted to let you know.

Im truely fascinated using mogre/ogre and Wpf together.
Welcome Oidamoh to our Ogre/Mogre world.
Nice to see that one more user tries to combine Mogre with WPF.

Since 3 weeks I learn WPF basics and try to build a tiny scene editor and an importer tool for my main application.
It's a good exercise for my first WPF experiences. I like the possibilities of WPF. I like it very much.
Well, currently I don't mix WPF with Mogre. Perhaps I will try it in the future.

Antialiasing problem
With the anti aliasing problem I can't help you.
Is the problem only related to Windows XP or also to Win7?

By the way - Mogre 1.7 supports only DirectX 9. (not 10 or 11)
Support for DirectX 10 and 11 is planned for Ogre 1.8.


Extra note:
When you post source code or log files in the forum, please use the CODE or QUOTE tag. (see edit toolbar)
It's for better overview.
Don't worry, I don't hit you. I just want to give you a tiny hint for the future.

Hi there thx for the warm welcome.

I'll try to structure my Posts better in the furture.

The Problem occurs only on Winxp because the direct3dex-Device is not available. For win7 and Vista you can use the d3d9ex-Device which is a Vista-predecessor für directX10 i assume.

My Problem is that the i cant use an antialiased Texture while using the d3d9-Device because it doesnt support antialiased Buffers... The result is as i mentioned. Nice staircases.

Ill try the AASettings for the window, but as i previously mentioned i think i've done that allready.

But thx anyway.

By the way - Mogre 1.7 supports only DirectX 9. (not 10 or 11)

Note: For Ogre (and Mogre), I implemented a Direct3D 9Ex plugin. 9Ex seems to be Microsoft's effort to bring some features of 10/11 (namely WDDM driver support, which is only available on Vista/Win7) back to the 9 world.

Oh, sound interesting (-:

Hi there,

The Antialiasing-Problem is fixed. I found a forumpost of a WPF-official where he stated that they restricted the setBackbuffer-Method to a nonAA-Texture because of compatibility issues with old graphic-cards.

The solution is unclean as simple. Render to an aa-Texture then copy to a "non-aa-Texture" and use this backbuffer in the setBackbuffer method of the d3dImage.

Another Topic arose... in the Sampleproject provided by maven there was a problem in this Method:


private void _isFrontBufferAvailableChanged(object sender, DependencyPropertyChangedEventArgs e)
{
if (IsFrontBufferAvailable)
AttachRenderTarget(true); // might not succeed
else
{
// need to keep old surface attached because it's the only way to get the front buffer active event.
DetachRenderTarget(false, true);
_imageSourceValid = false;//new
}
}

protected virtual void DetachRenderTarget(bool detatchSurface, bool detatchEvent)
{
if (detatchSurface && _imageSourceValid)
{
Lock();
SetBackBuffer(D3DResourceType.IDirect3DSurface9, IntPtr.Zero);
Unlock();

_imageSourceValid = false;
}

if (detatchEvent)
UpdateEvents(false);
}


If you open the taskmanager when running the app the Frontbuffer is not available. And the app is not able to recover the 3d-rendering. Just set the _imageSourceValid-Flag after the Detach-Call to false and the rendertarget gets reset sucessfully.

A small addition but it fixes that Problem.

Thx again to Maven. Now i have a running WPF-Mogre-App..

Greetz

The Antialiasing-Problem is fixed. I found a forumpost of a WPF-official where he stated that they restricted the setBackbuffer-Method to a nonAA-Texture because of compatibility issues with old graphic-cards.

The solution is unclean as simple. Render to an aa-Texture then copy to a "non-aa-Texture" and use this backbuffer in the setBackbuffer method of the d3dImage.

I'm glad you found a solution! Sounds like it may be a little performance hit? (Hopefully it's a copy within gfx memory.)

In case I need to do that too, how did you render to an AA texture in D3D9? You said it was only available in D3D9Ex?


Another Topic arose... in the Sampleproject provided by maven there was a problem in this Method:


private void _isFrontBufferAvailableChanged(object sender, DependencyPropertyChangedEventArgs e)
{
if (IsFrontBufferAvailable)
AttachRenderTarget(true); // might not succeed
else
{
// [raygun wrote this:] need to keep old surface attached because it's the only way to get the front buffer active event.
DetachRenderTarget(false, true); // [Mawen: if you set first param to true, it sets _imageSourceValid = false, and also sets D3DImage memory pointer to null]
_imageSourceValid = false; // [new from Oidamoh]
}


If you open the taskmanager when running the app the Frontbuffer is not available. And the app is not able to recover the 3d-rendering. Just set the _imageSourceValid-Flag after the Detach-Call to false and the rendertarget gets reset sucessfully.

A small addition but it fixes that Problem.


Thanks for the fix! I am not the author of this chunk of code (Leslie Godwin aka raygun wrote most of it), so I don't know if I messed this up, and I don't know if he intended it to be this way. Did you try passing true to the first parameter of DetachRenderTarget?

Leslie notes that you need to stay attached in order to "only way to get the front buffer active event", so maybe you are right in that you need to keep attached by not calling SetBackBuffer(..., Zero), but still need to set _imageSourceValid to false.

Anyway, once I can confirm the right thing, I can check it in to bitbucket. Maybe I will have time later to try it out.


Thx again to Maven. Now i have a running WPF-Mogre-App..


Awesome! Even more thanks to raygun! I am sure enjoying using WPF with Mogre, (and I hope it turns out to work well enough to ship in a game.)

Thanks for sharing this! I was actually working on my own variation of OgreInTheWpf when I searched for a Direct3D9Ex plugin for Ogre and found this instead, I only wish I'd found it a month ago

I also ran into problems when using multiple D3DImages with MOgre, but I found the solution - D3D needs to be created with the flag D3DCREATE_MULTITHREADED when used with D3DImage. Removing the #if/endif around D3DCREATE_MULTITHREADED in OgreD3D9DeviceManager.cpp was all that was needed. Without that fix I'd get random 10 second stalls when rendering.

Also on http://msdn.microsoft.com/en-us/library/cc656910.aspx they recommend setting the D3DCREATE_FPU_PRESERVE flag, that can be easily be done by calling root.RenderSystem.SetConfigOption("Floating-point mode", "Consistent"); before initializing the root.

I also massaged the API a bit:

RaySceneQuery raySceneQuery = sceneManager.CreateRayQuery(camera1.GetCameraToViewportRay(x, y), SceneManager.WORLD_GEOMETRY_TYPE_MASK);
Entity closestEntity = raySceneQuery.RaycastToClosestEntityMeshTriangle(ref /* Vector3 */ closestPoint, ref /* Vector3 */ hitNormal /*, bool calculateNormal = true by default */);

Which API did you improve?
Of your game? Of the code snippet in the wiki? Of a Mogre method?


The Antialiasing-Problem is fixed.
Thanks for your report.
I assume that it will help other people which have the same problem.

Thx again to Maven. Now i have a running WPF-Mogre-App..
Nice to know.

Also thanks to niall for the notes.

For more accurate ray hits have a look to this wiki page:
Raycasting to the polygon level - Mogre

...
I also massaged the API a bit:

RaySceneQuery raySceneQuery = sceneManager.CreateRayQuery(camera1.GetCameraToViewportRay(x, y), SceneManager.WORLD_GEOMETRY_TYPE_MASK);
Entity closestEntity = raySceneQuery.RaycastToClosestEntityMeshTriangle(ref /* Vector3 */ closestPoint, ref /* Vector3 */ hitNormal /*, bool calculateNormal = true by default */);

Which API did you improve?
Of your game? Of the code snippet in the wiki? Of a Mogre method?

Of the raycast code (snippet in the wiki) that you mentioned at the top of the post.

Just a tiny information:

By random I found a repository which contains an example with Mogre and WPF.
The URL wasn't posted in this forum (as I found out by a Google search).

So I mention it here:
https://awesomiumdotnet.svn.codeplex.co ... WpfSample/

More details I don't know.
Maybe the same code was published somewhere else.
Perhaps it's useful for somebody.

Update:
I searched a little bit in the web and found out, that this example is NOT a Mogre example.
It's shows interaction between AwesomiumDotNet and WPF.
AwesomiumDotNet can be used by Mogre. On the other hand the project development is stopped.
Just to let you know.

Hi there,

The Antialiasing-Problem is fixed. I found a forumpost of a WPF-official where he stated that they restricted the setBackbuffer-Method to a nonAA-Texture because of compatibility issues with old graphic-cards.

The solution is unclean as simple. Render to an aa-Texture then copy to a "non-aa-Texture" and use this backbuffer in the setBackbuffer method of the d3dImage.

I gave this a shot and it didn't seem to be working. Can you post your source?