Visual Studio 2008 with WPF vs. Visual Studio 2005 with XNA for creating Interactive 3D Applications
Traditionally considered the province of game development only, Direct X, OpenGL and similar technologies permit the creation of applications that put traditional forms to shame, especially when developers explore the possibilities offered by creating complex 3D environments for their users to explore and interact with.
In the past this meant building a costly and time consuming 3D engine, usually in C++ or similar, but a few years ago Microsoft released the highly acclaimed XNA which, while targeted at game development nevertheless could be used for in any application to easily get a 3D accelerated scene. Initially built into a specialized version of Visual Studio 2005 express, XNA 2.0 today can be installed with any version of Visual Studio 2005.
Perhaps the key technology of Visual Studio 2008 is WPF, and this provides a definite challenge to XNA’s 3D superiority. WPF is a technology that is entirely powered by DirectX and which seamlessly merges 2D with 3D in a windows environment, which leads to the question: when developing a 3D application, which is the better platform to develop with? Visual Studio 2008, or Visual Studio with XNA?
If you forget for a second that WPF is “targeted” at windows development whereas XNA, which can compile seamlessly for the Xbox 360 is “targeted” at game dev, ultimately they’re two highly sophisticated, highly evolved platforms for creating DirectX powered windows applications. There are a number of differences encountered between developing in each, and I believe that these lead to the conclusion that the ultimate choice is determined by your applications needs.
In traditional 3D engines, including those implemented through XNA, a central render loop forms the core of the application. This loop contains a draw method where each element of your scene is rendered, before the final image is flipped to the screen. In developing a 3D application in Visual Studio 2005 with XNA you construct your scene from 3D elements and sprites, and then make adjustments and render it on every call of the draw method. By counting the number of times this method is called each second the frame rate can be calculated, which with XNA the frame rate tends to sync with your screens refresh rate.
When starting a XNA application you are given a near blank slate, with the central game class containing the overridden draw method, along with methods for loading and unloading content. Defining the screen size or resolution is all done within the code, and the properties of your XNA window are largely irrelevant.
In Visual Studio 2008, when starting a new WPF project you will find that most of this low level engine behaviour is hidden. Much like when developing a windows application, where after adding a button to a form you don’t then have to catch the windows render method and ensure the button is painted, in a WPF project whether you add a 2D element or a 3D element, once added to the canvas they will be rendered on every frame automatically.
On top of this, the built in z-order rendering and transparency both make putting together a 3D scene almost as easy as putting together a 2D one. When constructing a scene a programmer need only define where each object is in 3D space, and where the camera is, in order to have a perfectly ordered scene show without any further configuration, complete with 2D elements appearing in the overlay.
This can be done in the code or with XAML on the canvas, and with predefined 2D elements like buttons and textboxes dropping elements with Visual Studio 2008’s visual editor feels very similar to Windows Forms in VS2K5, only with far more power and control.
This XAML above in Visual Studio 2008’s visual designer shows how easy it is to throw together a 3D scene complete with a camera and a directional light.
In comparison to construct a scene in XNA through Visual Studio 2005 requires a lot more work, especially in terms of interface elements. In a traditional graphics engine everything is 3D, and the best method to get an interface element on screen is to render it as a sprite, then apply it to a thin 3D object that is projected outside of the Z order, and therefore painted last over all other elements.
While this is a workable solution and with a bit of work easily achievable in .NET 2.0, developers will find throwing together a WPF equivalent in Visual Studio 2008 much, much easier.
Dropping a button on the screen, defining an event handler and properties and then having it work seamlessly with a 3D backdrop makes a very strong case for Visual Studio 2008 over any traditional 3D development platform.
In any interactive or animated scene the elements that make it up and the camera through which the user sees them often have to be moved and rotated, or created and destroyed. The way objects are moved and rotated in WPF is a little easier than doing the same in XNA, thanks to the addition of wrapper objects in Visual Studio 2008 like RotateTransform3D, where an object can be rotated along its axis through a one line command as simple as:
model.Transform = new RotateTransform3D(new AxisAngleRotation3D(new Vector3D(0, 1, 0), rotation), new Point3D(2.5, 2.5, 2.5));
Where the axis is set by the first vector, the amount (in degrees, not radians) is set by the variable rotation and the point to rotate around is set by the Point3D instance. Even such a simple thing as using degrees in a double instead of radians in a float demonstrates the central philosophy behind WPF and Visual Studio 2008; that of making things easier and more inline with traditional windows form programming, rather than following the precise and lower level conventions of graphics engine development as followed in XNA.
The big advantage of an XNA application over a WPF form is performance, and this may be critical in choosing between the two for a prospective 3D application. As XNA is essentially a graphics engine with extra bits tacked on, it has no need to ‘play nice’ with Windows like WPF and Visual Studio 2008 need to, and as such free from any such responsibilities it can run a lot faster when windowed or full screen.
Also, because the draw method is readily available in the auto generated classes created by VS2K5, code to alter the scene at runtime based on caught user input or whatever can be included in there, allowing the entire application to effectively run on one thread.
In WPF in Visual Studio 2008 by contrast two threads run by default, one for input and one for rendering, and if you wish to add scene altering behaviour via a timer or whatever the processor time allocated to your app starts to get sliced pretty thin.
This can lead to timer ticks becoming less precesise and in the worse case scenario interface response times getting a little laggy. XNA also makes use of XACT and a content pipeline, which while impractical in some situations has the advantage that it streamlines the process of loading content for rendering. In WPF the amount of power required to do something like this is many magnitudes greater than that used by XNA:
On top of this, while WPF and the libraries of .NET 3.0 packaged with Visual Studio 2008 possess all the basic Direct3D abilities, some of the more advanced stuff offered by DirectX is not available, such as complex filters. This puts it at a definite disadvantage to XNA and Visual Studio 2005 in terms of what level of graphical fidelity is available.
However in contrast, many of the more complex abilities supported by XNA rely on external tools beyond Visual Studio 2005, the most obvious is XACT for creating XNA Audio, a rather clumsy tool that comes packaged with XNA 2.0.
Other tools, for example Nvidia’s Filter Designer, are only available from third parties. Integrating content into a WPF application with Visual Studio 2008, by way of comparison, is as simple as adding images and sounds to your project through the solution explorer. What Visual Studio 2008 sacrifices in 3D power, it makes up for in usability.
Ultimately when choosing what platform to develop a 3D application in the choice between the Visual Studio 2008 with WPF and Visual Studio 2005 with XNA boils down to scale and ease. When your app requires more advanced, more precise rendering and/or requires a lot of power to run, the more fundamental XNA is your best bet. However, aside from performance, Visual Studio 2008’s WPF is superior to XNA in many ways, including in ease of development, integration with windows, and coding simplicity.
A simple WPF 3D app developed in Visual Studio 2008 can be developed in a fraction of the time it takes to do the same in VS2K5 with XNA 2.0, and will usually look just as good running side by side.
Other related posts:
The New Zealand ALM Conference 2011 (Application Life Cycle Management)
Writing your own Html Helpers for the ASP.NET MVC Framework
Automating Visual Studio 2008
Comment by Leo Natan, on 5-May-2008 07:04
Hey, thank you for this post! I'm now seriously considering choosing WPF for the 3D portions of my project. Another big reason to choose WPF is Visual Studio 2008 itself. XNA 3.0 (and its betas), with support for Studio 2008, is a long way off, while WPF is available now.