Return to Answer

You can definitely create similar kinds of interfaces in WPF, but integrating them into a Direct3D game is problematic. You can host Direct3D content within WPF (via D3DImage), but your 3D content would be composed into the WPF application, so rendering becomes dependent on WPF. Consequently, you might see relatively poor performance, as you are limited by WPF's frame rate. Also, as U62 noted in his comment, WPF can only host Direct3D 9 content (as opposed to Direct3D 10/11). However, you might be able to get around this, as IDirect3DDevice9Ex is capable of sharing resources between devices. Therefore, you could potentially create a shared render target in Direct3D 10 or 11 and bring it into WPF via an intermediate IDirect3DDevice9Ex device. Jeremiah Morrill discusses this technique here.

An alternative, though far from elegant, would be to render your WPF UI in a separate layered window above the Direct3D content, as described here.

There are also ways to access WPF's internal Direct3D surface, which would give you a way to host WPF content in an external Direct3D scene (instead of the other way around). However, this is a rather nasty hack and could easily be broken by future WPF releases.

Of course, none of this is relevant if you don't actually need to interoperate with Direct3D. Games that don't require complex 3D graphics can certainly be developed completely in WPF. WPF does have some simple 3D facilities at its disposal, though they are generally insufficient for anything beyond primitive shapes with simple textures. It also supports custom pixel shaders, though there are many restrictions (e.g. they must be single-pass effects).

You can definitely create similar kinds of interfaces in WPF, but integrating them into a Direct3D game is problematic. You can host Direct3D content within WPF (via D3DImage), but your 3D content would be composed into the WPF application, so rendering becomes dependent on WPF. Consequently, you might see relatively poor performance, as you are limited by WPF's frame rate. Also, as U62 noted in his comment, WPF can only host Direct3D 9 content (as opposed to Direct3D 10/11). However, you might be able to get around this, as IDirect3DDevice9Ex is capable of sharing resources between devices. Therefore, you could potentially create a shared render target in Direct3D 10 or 11 and bring it into WPF via an intermediate IDirect3DDevice9Ex device. Jeremiah Morrill discusses this technique here.

An alternative, though far from elegant, would be to render your WPF UI in a separate layered window above the Direct3D content, as described here.

There are also ways to access WPF's internal Direct3D surface, which would give you a way to host WPF content in an external Direct3D scene (instead of the other way around). However, this is a rather nasty hack and could easily be broken by future WPF releases.

Of course, none of this is relevant if you don't actually need to interoperate with Direct3D. Games that don't require complex 3D graphics can certainly be developed completely in WPF. WPF does have some simple 3D facilities at its disposal, though they are generally insufficient for anything beyond primitive shapes with simple textures. It also supports custom pixel shaders, though there are many restrictions (e.g. they must be single-pass effects).

You can definitely create similar kinds of interfaces in WPF, but integrating them into a Direct3D game is problematic. You can host Direct3D content within WPF (via D3DImage), but your 3D content would be composed into the WPF application, so rendering becomes dependent on WPF. Consequently, you will see relatively poor performance, as you are limited by WPF's frame rate. Also, as U62 noted in his comment, WPF can only host Direct3D 9 content. However, you might be able to get around this, as IDirect3DDevice9Ex is capable of sharing resources between devices. Therefore, you could potentially create a shared render target in Direct3D 10 or 11 and bring it into WPF via an intermediate IDirect3DDevice9Ex device. Jeremiah Morrill discusses this technique here.

An alternative, though far from elegant, would be to render your WPF UI in a separate layered window above the Direct3D content, as described here. There are also ways to access WPF's internal Direct3D surface, but this is a rather nasty hack and could easily be broken by future WPF releases.

Of course, none of this is relevant if you don't actually need to interoperate with Direct3D. Games that don't require complex 3D graphics can certainly be developed completely in WPF. WPF does have some simple 3D facilities at its disposal, though they are generally insufficient for anything beyond primitive shapes with simple textures. It also supports custom pixel shaders, though there are many restrictions (e.g. they must be single-pass effects).

You can definitely create similar kinds of interfaces in WPF, but integrating them into a Direct3D game is problematic. You can host Direct3D content within WPF (via D3DImage), but your 3D content would be composed into the WPF application, so rendering becomes dependent on WPF. Consequently, you might see relatively poor performance, as you are limited by WPF's frame rate. Also, as U62 noted in his comment, WPF can only host Direct3D 9 content (as opposed to Direct3D 10/11). However, you might be able to get around this, as IDirect3DDevice9Ex is capable of sharing resources between devices. Therefore, you could potentially create a shared render target in Direct3D 10 or 11 and bring it into WPF via an intermediate IDirect3DDevice9Ex device. Jeremiah Morrill discusses this technique here.

An alternative, though far from elegant, would be to render your WPF UI in a separate layered window above the Direct3D content, as described here.

There are also ways to access WPF's internal Direct3D surface, which would give you a way to host WPF content in an external Direct3D scene (instead of the other way around). However, this is a rather nasty hack and could easily be broken by future WPF releases.

Of course, none of this is relevant if you don't actually need to interoperate with Direct3D. Games that don't require complex 3D graphics can certainly be developed completely in WPF. WPF does have some simple 3D facilities at its disposal, though they are generally insufficient for anything beyond primitive shapes with simple textures. It also supports custom pixel shaders, though there are many restrictions (e.g. they must be single-pass effects).

You can definitely create similar kinds of interfaces in WPF, but integrating them into a Direct3D game is problematic. You can host Direct3D content within WPF (via D3DImage), but your 3D content would be composed into the WPF application, so rendering becomes dependent on WPF. Consequently, you will see relatively poor performance, as you are limited by WPF's frame rate. Also, as U62 noted in his comment, WPF can only host Direct3D 9 content. However, you might be able to get around this, as IDirect3DDevice9Ex is capable of sharing resources between devices. Therefore, you could potentially create a shared render target in Direct3D 10 or 11 and bring it into WPF via an intermediate IDirect3DDevice9Ex device. Jeremiah Morrill discusses this technique here.

An alternative, though far from elegant, would be to render your WPF UI in a separate layered window above the Direct3D content, as described here. There are also ways to access WPF's internal Direct3D surface, but this is a rather nasty hack and could easily be broken by future WPF releases.

Of course, none of this is relevant if you don't actually need to interoperate with Direct3D. Games that don't require complex 3D graphics can certainly be developed completely in WPF. WPF does have some simple 3D facilities at its disposal, but it's generally insufficient for anything beyond primitive shapes with simple textures.

You can definitely create similar kinds of interfaces in WPF, but integrating them into a Direct3D game is problematic. You can host Direct3D content within WPF (via D3DImage), but your 3D content would be composed into the WPF application, so rendering becomes dependent on WPF. Consequently, you will see relatively poor performance, as you are limited by WPF's frame rate. Also, as U62 noted in his comment, WPF can only host Direct3D 9 content. However, you might be able to get around this, as IDirect3DDevice9Ex is capable of sharing resources between devices. Therefore, you could potentially create a shared render target in Direct3D 10 or 11 and bring it into WPF via an intermediate IDirect3DDevice9Ex device. Jeremiah Morrill discusses this technique here.

An alternative, though far from elegant, would be to render your WPF UI in a separate layered window above the Direct3D content, as described here. There are also ways to access WPF's internal Direct3D surface, but this is a rather nasty hack and could easily be broken by future WPF releases.

Of course, none of this is relevant if you don't actually need to interoperate with Direct3D. Games that don't require complex 3D graphics can certainly be developed completely in WPF. WPF does have some simple 3D facilities at its disposal, though they are generally insufficient for anything beyond primitive shapes with simple textures. It also supports custom pixel shaders, though there are many restrictions (e.g. they must be single-pass effects).