none
DirectX interop and the upcoming D3DImage RRS feed

  • Question

  • Hey guys, I am working on a project requiring WPF for UI development, however, also requires some heavy 3D rendering as well. The 3D capabilities of WPF have so far not been adequate so I have had to resort to DirectX interop to get the desired performance. I have a pretty functional real-time render engine tied to a UI control that works great, but I would like at some point to have the ability to place WPF controls on top of the render target.

    I have used Petzold's "airspace overlay" approach, and that works fine as long as the DX content is only rendered once or on resize. But I have to do real-time rendering, and this has a tendency to conflict with the overlaid WPF content causing severe flickering.

    So my question is two-fold:
    1) Is there an approach I can use that currently exists that will work in my scenario
    2) How is the up and coming D3DImage from 3.5SP1 going to work? Is it going to have the performance that I need? Can controls be overlaid on the image? More importantly, how is one going to be able to implement it? Since MS decided to drop support for Managed DX, how is the DirectX render code going to be handled?

    Any help would be appreciated!

    Thanks
    Friday, May 16, 2008 5:18 PM

Answers

  • Could you elaborate on why WPF3D is not adequate? Are there missing features you need or is it just perf? Are you hitting a wall due to number of vertices? Number of models? Any feedback would be helpful.

    Is the airspace overlay the standard layered window technique? If so, I don't know another way to do it.

    Regarding D3DImage:

    Performance -- Naturally, it's not going to be as fast as pure D3D code because the rest of WPF and the CLR is going but in our testing so far, we've been happy with it. It's hard to make a blanket performance comment about D3DImage because using it does require a flush of your device and that performance is dependent on the driver and scene complexity. Like if you had asked me if I thought we would get 30+ FPS on the 8 D3DImage cube app shown in David's Channel 9 video, I would have said no way. But it works!

    Ovelay -- Yep. D3DImage is a standard ImageSource so you can put it in ImageBrushes and Images.

    Rendering -- The primary scenario is writing unmanaged D3D code where you pass the IDirect3DSurface9* up to managed code. We have had people successfully use C++/CLI D3D code and MDX with D3DImage. XNA will not work. SlimDX will probably work but we have not tried it.

    One tricky thing with the managed DX implementations is that for good performance on Vista you will need an IDirect3DDevice9Ex device. With MDX I believe you can create the IDirect3DDevice9Ex in unmanaged code and then wrap the Device object around it. I don't know if you can do that with SlimDX.

    BTW, D3DImage is not in the Beta 1 that was just released.


    Friday, May 16, 2008 6:06 PM

All replies

  • Could you elaborate on why WPF3D is not adequate? Are there missing features you need or is it just perf? Are you hitting a wall due to number of vertices? Number of models? Any feedback would be helpful.

    Is the airspace overlay the standard layered window technique? If so, I don't know another way to do it.

    Regarding D3DImage:

    Performance -- Naturally, it's not going to be as fast as pure D3D code because the rest of WPF and the CLR is going but in our testing so far, we've been happy with it. It's hard to make a blanket performance comment about D3DImage because using it does require a flush of your device and that performance is dependent on the driver and scene complexity. Like if you had asked me if I thought we would get 30+ FPS on the 8 D3DImage cube app shown in David's Channel 9 video, I would have said no way. But it works!

    Ovelay -- Yep. D3DImage is a standard ImageSource so you can put it in ImageBrushes and Images.

    Rendering -- The primary scenario is writing unmanaged D3D code where you pass the IDirect3DSurface9* up to managed code. We have had people successfully use C++/CLI D3D code and MDX with D3DImage. XNA will not work. SlimDX will probably work but we have not tried it.

    One tricky thing with the managed DX implementations is that for good performance on Vista you will need an IDirect3DDevice9Ex device. With MDX I believe you can create the IDirect3DDevice9Ex in unmanaged code and then wrap the Device object around it. I don't know if you can do that with SlimDX.

    BTW, D3DImage is not in the Beta 1 that was just released.


    Friday, May 16, 2008 6:06 PM
  • Could you elaborate on why WPF3D is not adequate? Are there missing features you need or is it just perf? Are you hitting a wall due to number of vertices? Number of models? Any feedback would be helpful.

    The short answer is "yes" Smile The long answer is that the complexity of what I need is really pushing me to a DirectX approach because of the necessity of using custom vert/pixel shaders for highly complex 3D models that will animate. I tried loading the models into WPF and animating them, but the CPU usage spiked to 50%+, memory usage was high, and the framerate was terrible. So it really is a performance issue, and while there may be some workarounds or optimizations, I am comfortable with DirectX development and the performance is quite the bonus.

    Is the airspace overlay the standard layered window technique? If so, I don't know another way to do it.

    Indeed it is. I am creating a second transparent window above the DirectX control and placing WPF content there. It works fine for event responsive render techniques, but I am using a real-time approach with a seperate render thread. I have the render tied to the Vsync, and the 3D render is great, but it causes the WPF content to flicker after resizing the window/control. Sometimes it will flicker, other times it won't. I know exactly why it is doing this of course, and I get the feeling that I cannot really stop this, but I am asking just in case.


    D3DImage Stuff


    This all sounds very, very interesting, and seems like it will be a fantastic solution to what I want to do. Ultimately, I could barge ahead with what I am doing and just ignore having the capability to display WPF content over the 3D content, but I really, really want WPF content. This seems like it could be the answer.


    As for MDX, I would really like to stick with this if possible. I know MS hates it and wants it to disappear with the advent of XNA (which is a decision I am a little disappointed with), but MDX has made working with this project so much easier, as it is nearly impossible to convince those making decisions to try an unmanaged solution.


    Has any thought been put into bringing MDX out of retirement for the sole purpose of helping developers with the implementation of the D3DImage? It seems that all that would have to be added would be that one wrapper, which does not seem like it would be difficult for anyone who has any experience writing them. MDX was pretty feature complete (at least feature complete enough for me) at the time of its axing.


    Maybe I should keep dreaming Wink


    Friday, May 16, 2008 7:28 PM