I have an industrial C#/WPF application written that needs to render thousands of 3D lines. (N.B. these are not a wireframe - they do not necessarily represent a 3D surface, so I don't want to tesselate polygons into triangles, or do lighting a shading, but I do want hardware acceleration) I've been looking at OpenGL and Direct3D but I keep seeing XNA suggested on Stack Overflow, e.g., here and here
I went to https://en.wikipedia.org/wiki/Microsoft_XNA to try to understand it but I'm still confused. Is it just a wrapper for something I should be using directly, like Direct3D? Does it give me access to the underlying graphics API? Can it even do lines? Can I run it in a WPF object like a Panel or Canvas?
Is it just a wrapper for something I should be using directly, like Direct 3D
XNA is not a 1:1 of DirectX.
Though XNA uses DirectX under the hood it's generally not correct to think of it as "just a wrapper" for DirectX. XNA does a few things that DirectX doesn't, like content pipelines; a clearly-defined separate game loop and draw point; content load and unload callbacks; and 2D sprites. (Microsoft ditched 2D drawing DirectDraw for a time and only now have released Direct2D)
XNA consists of a series of layers starting with Platform being the lowest and includes APIs such as Direct3D 9; XACT; and XInput.
Building upon Platform you'll find Core Framework; Extended Framework; and Games which abstract; encapsulate the lower layers whilst adding new features that result in "making game development easier". [1]
The end result is so far removed from DirectX (except perhaps for the shaders) you would not be aware you are using DirectX. You can have a game window up and running in a few lines of code compared to DirectX's pages and pages of code.
Does it give me access to the underlying graphics API?
If you mean can you talk directly to DirectX COM API then no, you can't. You can however write shaders that when compiled, the GPU will understand indirectly.
Can it even do lines?
Yes.
Can I run it in a WPF object like a Panel or Canvas?
Apparently so. I should point out that WPF already is hardware accelerated and uses DirectX for rendering. Even those drop shadow effects you see in WPF are actually DirectX GPU shaders.
Today
As you have probably read, XNA is deprecated and though Monogame is active is not 100% compatible with XNA (just look for the many posts on SO regarding XNA Content Pipeline issues for one).
Therefore if you are wishing to do 3D in WPF, well you don't need XNA for that.
More
[1] Cookiecups, "what is the xna framework", MSDN Blogs
I'm currently in the early stages of a project and have difficulty deciding which framework to use. I hear people say WPF is dead, yet it seems to be the (only?) way to program a Microsoft Surface app. This is one of the possible future aims of the project, but not the main focus.
The main focus however is: both 2d and 3d objects in the same view (and kinect/voice support). Some of the 2d objects are SVG files. From what I have read online so far it's not easy to render SVG graphics in XNA (nor Silverlight 5 3D for that matter). I've seen some SVG to XAML converters, but could the result of this be used in a 3d view? Or vice versa?
Considering it's not going to be a game, but a business application I'm tempted to rule out XNA, but then again I also require good performance as there will be quite some graphical stuff going on and if possible support for high resolutions/video wall. Taking a video wall into consideration would maybe rule out WPF as I've read that it will only use hardware acceleration if the resolution is lower than the texture size limit of the GPU.
There is no intend to run the application in the browser or phone, as such i'm tempted to rule out Silverlight 5.
Any tips would be greatly be appreciated.
Thanks!
I wouldn't rule out XNA on the basis that it's "for games". You can simply use only the parts required for hardware-accelerated 3D rendering and ignore the rest. This is in fact what Silverlight 5 does!
So you may find that your 3D rendering code is the same between XNA and SL5 in any case.
Here is a question about SVG in XNA. Basically answer is: you have to write your own hardware-accelerated SVG renderer - a stupidly difficult task. But if your SVG files never change, you could just use an existing software renderer to render them to a texture.
If you converted your SVG to XAML, you would have to render it to a texture to use it in a SL5 3D view anyway (unless it's an overlay). So there is no big win there. I don't know how 2D-3D compositing works in WPF.
Your decision really depends on whether you would find the built-in functionality that SL5 or WPF provides for user interfaces useful? Seeing as you are basically making your own user interface, you probably would not get much use from the provided 2D interface.
The 3D API that SL5 provides is basically a cut-down version of XNA. The 3D API for WPF looks like it just renders models for you - it does not seem to buy you much over XNA. If you have a compelling reason to use XAML, then WPF may be a good choice. Otherwise I'd go with XNA.
I learning wpf/silverlight currently. I want to ask which one of them is better for graphics, 3d, ... ?
People say "Silverlight is a subset of WPF" -- what they mean is that the programming model is the same (code + XAML), but Silverlight generally has a smaller API / less features than WPF.
I think a good example would be creating a reflection. In WPF you could use a VisualBrush, but Silverlight doesn't support it. Still you can create the same effect by creating a 2nd transformed element. You can pretty much acomplish the same task in both, although for Silverlight you may have to do some processing tasks on the server.
The choice of platform depends more on whether you want to target web deployment or not and possibly performance.
3D isn't implemented in Silverlight 4 (though there are 3D libraries out there). 3D will be part of Silverlight 5. (Beta coming soon, probably at MIX, and to be released this year.)
i would sugest wpf in WPF you have all the Viewport sutff where you can do real 3d, In Silverlight you have PlaneTransformation but it is not close to real 3d
WPF 3d tutorial
The deal is more deeper as I understand.
We will speak about WPF and Silverlight 5. There are two mechanisms of 3D Graphics. Before WPF it was a single one - so named pipeline graphics. It includes DirectX, OpenGL and multiple derivative and independent realizations (XNA from DirectX, for example). Although WPF is based internally on DirectX it realizes absolutely different conception of smart graphics. What is the difference for a pipeline and smart mechanism? The pipeline mechanism consists of infinity loop of drawing objects - typically primitives like vertex, triangles. It works by initialization of so named infinity loop by calling something like OnDraw/ReDraw method.
WPF does not use ReDraw and does not draw anything until we directly detect it. It is single correct way to use it. Therefore WPF allows to draw UI Elements with internal support of hundreds events, methods and full freedom of management (like usual WPF control - textbox, for example). (Helix 3D is good library for easy way to WPF 3D) And vice versa, Silverlight 5 has some API of XNA graphics - pipeline way without UIElement support for 3D objects.
There is Kit3D library http://kit3d.codeplex.com/ as very good idea for smart graphic realization for Silverlight and there are many other realizations (Balder, Babylon) on pipeline mechanism. If you are interesting to code an application like web 3D Game - choose pipeline Silverlight 3D graphics, if you are interesting about smart 3D applications - choose WPF 3D.
Author of WPF 3D CAE system TIMO Structural.
In my company we have in mind a redesign of the user interface of an application and we would like to make it ... let say "fancy". We have in mind a simple story board but I doubt between WPF, XNA or DirectX. I prefer WPF so I'd need to know if it support the following capabilities and how difficult to implement are they:
Transparency: We'd like to display information layers on top of the main display.
3D support: We want network nodes (part of the interface is a network graphic) to be simple spheres connected with lines in a 3D enviroment, and the ability to control the camera so rotation of the screen is possible.
Effects: Such as shading, lens flare or glow to "signal" the discovery or deletion of a node.
Text animations: Specifically the ability to display the text as if it's being written... You know, the information text will be "filling" the panel top down, left to right...
Good news. WPF is the technology you want and it can handle your requirements with relative ease.
Transparency is simple.
3D support is good as well. For an example, check out Tim Sneath: Five Great WPF 3D Nuggets. You even get hardware acceleration.
Effects are definitely do-able via timeline animations.
The previous statement goes double for Text Animations.
...the hardest part would be the 3D support, but it's still going to be a lot easier than getting things done in XNA or using DirectX libraries directly.
AFAIK WPF 3.5 supports all of this, and even leverages hardware acceleration to get a decent performance.
It's possible to embed an XNA application in a WPF form so you could use XNA for the representation of your network and WPF controls for the GUI in front of it.
I am programming simple Windows apps. I don't need DB support. Why would I use WPF instead of WinForms?
One obvious answer is that WPF offers a richer user experience than WinForms, allowing for animations (even 3D) in the user interface, for example.
From a development perspective, it goes a long way to enforce the separation of the User Interface (in the XAML) from the business logic (in VB.NET or C#), which is always a good thing.
A Google search for "WPF vs WinForms" brings up lots of pages that discuss this issue. I won't repeat all their findings here, but this page raises some interesting points:
Databinding in WPF is superior to what Windows Forms offers.
UI and C# business logic can be cleanly separated in WPF
Storyboard
Data/control templates – a much cleaner way than anything Windows
Forms can offer.
Styles – cool and simple. Its so easy to style all your buttons in an
application to have the same look and
feel.
Even if the VS designer breaks, its easy to code XAML.
UI virtualization – I’ve got grids with 100K rows, ticking off a moving
market. Performance would be dreadful
if it wasn’t for UI visualization
which come for free.
3D support.
Nothing scientific but, UI development feels quicker in WPF –
maybe its just because a WPF
application looks cooler at the end of
an iteration, or maybe its because
development really is quicker.
I can add a User Experience engineer to my team, and with no C#
knowledge he can work magic in
Expression Blend and give the
front-office trading application a
makeover that is guaranteed to win
over the business users.
WPF is the current platform for developing Windows desktop applications. It is a modern, advanced, hardware accelerated framework for developing applications that maintain separation of concerns. It supports advanced rendering of 2D vector and 3D graphics, providing an immense range of capabilities for building rich, interactive, and quality user interfaces.
WinForms, on the other hand, provides a basic platform for developing "classic" Windows apps with your standard look and feel using standard controls. It does not offer the rich, hardware accelerated, vector 2D and 3D capabilities that WPF offers. WinForms applications tend to have much greater coupling between application behavior and UI (view), which presents a less flexible platform upon which to develop applications.
As for which one you choose, it entirely depends on your needs. If you need vector graphics, 3D rendering, the ability to create rich, interactive, animated, modern user interfaces, and/or wish to maintain separation of concerns, WPF is definitely the right choice. If you need none of that, and just need to create a simple UI that solves a simple problem, WinForms will meet your needs just fine.
To learn.
To have greater (i.e. any) control over the appearance of your program
To benefit from easier data binding, triggers, styles
(I don't see what DB support has got to do with it)
WPF can utilize hardware acceleration to some degree, but that is expected to improve over time.
Also, because of XAML, you have more options for "doing stuff", declarative vs. programmatic, or a mixture of both.
Microsoft no longer does active development on WinForms, they are strongly pushing WPF, and for good reason.
WPF allows for much easier "resolution agnostic" designing. To achieve that in WinForms, it is a lot more work.
The MVVM pattern was already mentioned in one of the comments, this allows one to do real unit testing vs. GUI-based testing on your code, that is a big win, in my experience.
Nobody mentioned about better testing capabilities of the WPF applications (if they are written in the correct way, for example based on the MVVM pattern).
A
Anywhere Execution due to XAML.
Can be used as WinApp, WebApp, Mobile.
Whereas WindowsForm Internal UI representation is in C#.
B
Binding -->Simple object to object data transfer.
C
Common look and feel(Styles) -->can define look and feel styles commonly and use it for bunch of controls.
D
Directive Programming -->Binding objects in XAML.
E
Expression blend and Animation-->WPF uses DirectX, and DirectX can be used for animation.
F
Faster Execution(Hardware Rendering)
WPF internally uses DirectX (Hardware rendering) while Winform internally uses GDI (mostly uses Software rendering).
There are two ways by which a computer renders display on monitor.
1) (CPU) Software rendering -->In case of CPU rendering ,the CPU drives the whole logic of rendering display on monitor.CPU also does other operations like running applications,performing memory management,running OS. So on top of it its extra load to display things on monitor.
2)(GPU) Hardware rendering -->Its Specialized kinda processor, specifically meant for rendering and display faster on monitor.
Now in WPF, this rendering is further optimised in
>Tier 0 mode (Software rendering) uses DirectX7 internally,
>Tier 1 mode (Partial Hardware rendering) uses DirectX7 to DirectX9 internally,
>Tier 2 mode (Hardware rendering) uses DirectX9 internally.
G
Graphic Independence (DIP) -->Means resolution independence
Resolution --> Total number of pixels that fits into screen/monitor
Pixel --> Simple dot on screen.
Windows form uses pixels as a measurement unit, so when pixel changes then win forms has to adjust itself that means we have to write logic for it.
But WPF does not use pixels as a measurement unit but uses DIP(Device independent pixels)
1 DIP = 1/96th of the inch.
At last Testing --> Better unit testing with use of MVVM pattern.
If you want to have a rich user interface like the image posted in your previous question, I'd recommend going with WPF. Aside from making it easier to create a nice-looking application, it's also the technology Microsoft will push in the future. There's almost no new development for Winforms.
The single most important difference between WinForms and WPF is the fact that while WinForms is simply a layer on top of the standard Windows controls (e.g. a TextBox), WPF is built from scratch and doesn't rely on standard Windows controls in almost all situations.
A great example of this is a button with an image and text on it. This is not a standard Windows control, so WinForms doesn't offer you this possibility out of the box. Instead, you will have to draw the image yourself, implement your own button that supports images or use a 3rd party control. With WPF, a button can contain anything because it's essentially a border with content and various states (e.g. untouched, hovered, pressed).
check this article it will help you:
https://www.wpf-tutorial.com/about-wpf/wpf-vs-winforms/#:~:text=The%20single%20most%20important%20difference,controls%20in%20almost%20all%20situations.