This is what I have to do:
To build a CAD-like application that loads a point cloud (i.e. thousands of 3D points representing a 3D object) from file, allows the users to manipulate the points (i.e. change the shape by moving the points), do a lot of calculations the points on the points (e.g. finding the intersection points between lines and surfaces, detect a point is above or under a surface etc., measure the distances between points, or points to surface etc.), and then save the modified points to file.
It also provides basic CAD-like UI features such as zoom in/out, pan the view, rotation the camera etc.
Speed is the major concern.
Instead of writing my own functions for matrix operation and defining my own point/line/surface classes, I would like to use existing libraries/APIs to do the job.
I know WPF, XNA and SlimDX provides the API to do 3D geometric calculations and all of them are finally calling DirectX, but I'm just newbie to all of them. I'm wondering:
Which one (or some other suggestion) could give better performance in speed.
My understanding about DirectX's 3D functions is that it mainly deals with gaming graphics / screen outputs, is it also suitable for data-level calculations(i.e. use the 3D functions to manipulate the point data, calculate the distances etc., but not outputting it on the screen)? By suitable, I mean if I create thousands of DirectX vertexes and mainpulate them, would it be much slower than using my own data types and structures?
Pls correct me if my understanding is wrong.
If I use WPF, do I need to use XNA as well? I'm kind of mixing up these two things.
The application is supposed to run in research lab's PC which doesn't have powerful gaming display card, so does it mean XNA is not preferred?
An suggestion about the technologies should be used for this application?
Thanks!!
========update
To make it clearer, the app will load ~108,000 points in 3D, and every points will form surfaces with other adjacent points, so roughly the the same number of 3D surfaces are involved (I'm not generating them at the same time). I will do a lot of 3D geometric and matrix calculations with the point and surfaces, such as intersection, interpolation, transformation etc. , so the speed of the "calculations" is my major concern. Most of the time I will only draw the final result to the screen and the drawing is mainly lines and points, the speed of "drawing" is not a big concern . so it is not really a graphic-intensive app, but a geometric-calculation-intensive app.
After reading the answer and comments, I think of two options:
store & calculate the data with primitive data-types, and convert data to the WPF/XNA/SlimDX data structures when drawing them on screen, or
use these API's data structures to store, calculation and drawing all those points.
which one is better?
Honestly, if performance is your
primary concern I would go with the
API that gets you closest to the
hardware. Less obfuscation = more
speed. In that case, from the
choices you've provided, SlimDX
is the best option, followed by XNA,
and lastly, WPF.
No, DirectX must use efficient data structures and algorithms. Think about it-- would games that utilize DirectX be able to run at a suitable framerate if all DirectX calculations were inherently slow?
No, WPF and XNA are mutually exclusive. WPF is a framework for creating responsive and intuitive user interfaces. XNA, on the other hand, is a framework for creating games.
Not necessarily. What it actually means is that WPF is not preferred, as WPF will offload a lot of work to compatible video cards. If WPF is unable to find a suitable video card, the CPU will take that work instead, resulting in poor performance.
As I said before, for a graphics-intensive application such as the one you have described, the closer you can get to the hardware is the better. Native DirectX or SlimDX are good options.
Have you considered developing your functionality as a plugin for an existing CAD environment?
AutoCAD, for example, has a very powerful c++ sdk (ObjectARX), it also provides a managed .NET API. You can use c# and WPF to develop your extensions. It has existing geometry libraries you can reuse.
Certainly AutoCAD has its price, but there are alternatives. For example BricsCAD. I'm not sure if BricsCAD provides a .NET api though.
Developing an application from scratch would take weeks if not months.
If I were to develop your functionallity as an AutoCAD plugin it would take me a day.
Consider if you really need to roll out own your own 'CAD' environment.
A few weeks ago, I checked out the limits of XNA. I want to know how much billboards (GPU accelarated) the engine in able to deal with. The result:
Pure XNA: 350k billboards
XNA as rendering context in WPF: 100k billboards
I do not realy know why the engine slow down when rendering to a WinFormHost control. Some debugging shows, that GraphcisDevice.Present()
Related
There is a 3D simulation I made with helixtoolkit.wpf, but it is not effective at all in terms of performance. How can I adapt this project to SharpDX? I could hardly find any information about it on the internet. Is there a resource or shortcut you can recommend?
That would be a total rewrite. HelixToolkit and SharpDX is in no way compatible in scope.
HelixTookit is a wrapper around Wpf and provides a bunch of convenient controls and functions to easily display viewports with navigation etc.
SharpDX is a wrapper around Direct3D, so provides a much lower level access to the hardware. But you would need to write a lot of components yourself to be able to provide anywhere near the level of functionality of Helix. SharpDX is also no longer maintained, so you would spend a lot of time porting to a effectively dead technology.
As always with performance you should start with profiling. Is it really Helix3D that is the bottleneck? Or are you using it in a way that is inefficient? Before doing a major rewrite you should be certain you have explored all other options for performance optimization.
One thing you might try is to export your model to a file and open it in the windows 3D viewer, I suspect that uses the same underlying wpf code to display 3D models, so it should give a fair estimation of the possible performance.
I would like an example on how to draw a sphere, with texture on it (e.g. checkered), in modern XNA (as per MonoGame). Everything should happen programmatically (model and texture are generated, not loaded from files). Brief and tractable is a plus.
The end result would look like
except for the shadow and the fact that I don't care how exactly texture deforms towards the edges.
Indicating prior research: I've tried SpherePrimitive but could never put texture on it. If you can, consider it is already present. I have also tried this example from the web, it didn't compile agains MonoGame, when it did the end result did not look like a sphere.
A bit of context: I'm using XNA because it looks like the only cross-platform way to do 3D in C#, but I'm doing a simple visualization so I only ever need spheres so far.
It turns out that XNA/MonoGame is a particularly poor fit for that task. Contrary to my expectations it is not a 3D game builder, but 3D game engine builder. APIs provided are too low-level to tackle the described task in one go.
I have tried Unity 3D but it makes development Unity-centric, which is a nuisance given that I already have code base and tooling selected.
I am currently settling for using OpenTK for the job. It is still fairly low-level, but:
It is a no-frills solution. Create window when needed, dispose when done. It doesn't force a certain mindset, tooling or entry point, being a library.
It is basically OpenGL, for which there's a huge amount of code already written and available for review.
It's one small and stable dependency. Smaller number of layers of indirection.
I have already found a working textured sphere-drawing example
I'm new to SlimDX and working in a legacy system. There's a Direct3D11 device being used, but I'm trying to use CreateSphere from:
SlimDX.Direct3D9.Mesh.CreateSphere(Direct3D9.Device,...)
Is there any way to use CreateMesh with a Direct3D11 device? Casting to Direct3D9.Device is not a valid cast. I don't understand why a newer API would remove a feature as simple as creating a sphere.
The problem with your question is that you're mixing up two very distinct things.
The DirectX API didn't have a CreateSphere method, ever. This was contained in a helper library, DXUT, which was discontinued by Microsoft.
Just write your own or use a pre-made mesh. If you don't know how, you were probably relying too much on the helper libraries anyway.
Of course, your level of understanding is betrayed by the feeling that creating a 3D sphere is somehow a simple task. It's not. There's tons of different ways to generate even 3D primitives that depend a lot on what you're doing, that's probably one of the reasons DXUT was discontinued in the first place. There's many ways to arrange the vertices of a sphere (UV sphere, Icosphere, ...), many ways to index those, many different vertex formats which need to be filled differently based on what you're doing.
It still made sense to have those helper libraries when these problems simply weren't there - before the days of the programmable graphics pipeline. The old fixed pipelines were pre-made for relatively simple tasks, today you have much more flexibility, for some cost in having to understand how some things are done - things like HLSL, texture mapping, light calculations etc.
Going to create a small game with OpenGL as a side project. Going to be a top down shooter with emphasis on large numbers of enemies (the more the merrier)
Thinking about having the resolution max out at 800x600 (for an old school feel)
What language would you recommend, is C# capable of handling the number of entities I want on screen (60-100) or should I try out C or C++ or even some other language.
Do you have any other suggestions when going for a project like this, special documentation you recommend etc.
C# is easily capable of handling a few hundred objects at once. The real speed issues come from rendering, which will not be in C# space, and possibly any computation you want to be done for each object, such as physics. Ideally you'd be using a library such as Box2D or Chipmunk for that anyway, making C# speed a non-issue there as well.
I'd personally be willing to write a game such as this in even-higher level languages than C#. C# should easily suffice.
On the scripting languages tip, consider the excellent Pygame in python:
http://www.pygame.org/news.html
Or the newer LÖVE in Lua
http://love2d.org/
For a top-down shooter both are probably excellent choices.
Have you considered Haskell, D, or ADA?
C# will definitely be able to handle a paltry 60-100 OpenGL-rendered entities on any reasonable hardware.
Generally, for a project of this scope I would recommend using whatever language you want to learn next.
Your project scope isn't huge, but is meaty enough that it would probably stretch your knowledge of the language you choose a bit. So choose one you want to get better in.
I've only ever dabbled with it but LWJGL will facilitate a Java version. All of the in-house games at puppygames.net are done in Java with LWJGL, for instance, and curiously they too are top-down or side-on blaster style games.
I've created a workflow/flowchart style designer for something. At the moment it is using relatively simple Bezier curve lines to connect up the various end points of the "blocks" on the workflow.
However I would like something a bit more intuitive for the user. I want the lines to avoid obstacles like other blocks (rectangles) and possibly other lines too.
I prefer the bezier splines rather than polylines because they are prettier and seem to fit in better with the designer in general. But am willing to compromise if they are much harder to accomplish.
I know there is a whole load of science behind this. I've looked into things like Graphviz, Microsoft's GLEE and their commericial AGL (automatic graph layout) library.
GLEE seems to barely be production worthy. And their commercial alternative is, well, a commercial alternative... it's quite expensive.
Graphviz doesn't seem to have been ported to .NET in any way.
I have seen a polyline implementation used by Windows Workflow Foundation for its "freeform designer". And this works, just, but it is not really of production grade appearance.
I'm surprised there isn't some plug'n'play .NET library for this type of thing? Something like:
Point[] RoutePolyline(Point begin, Point end, Rectangle[] rectObstacles, Point[] lineObstacles);
I haven't tried it (although I'm a happy customer of their Gantt product), but ILOG have a similar tool here.
To quote:
The ILOG Diagram for .NET algorithms
share generic goals such as:
Minimizing the number of overlapping
nodes
Minimizing the number of link
crossing
Minimizing the total area
of the drawing
Minimizing the number
of bends (in orthogonal drawings)
Maximizing the smallest angle formed
by consecutive incident links
Maximizing the display of symmetries
Supporting incremental layout,
partial layout, subgraphs,
intergraph links and nested layouts
Perhaps worth a look, at least.
Diagram.NET is a free, open source diagramming library in C#. It hasn't been updated in quite some time, but it's certainly worth a look - there may something there which you can reuse.
http://www.dalssoft.com/diagram/
Are you limited to managed code only?
I did not have this restriction and the past and effectively integrated GraphViz with .Net. What we did was call an external process containing the natively compiled "dot" and parse the result in a .Net object model. It worked perfectly and was fast enough for our needs.
I'm sure you could do better and easier with C++/CLI today.