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.
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 have an old application for playing video that uses DirectX and I would like to update it and prevent the "error" of Loader lock among other things.
Can I ask what are the basic steps for converting the application? What do I have to pay special attention to?
Currently I have references in the project that point to local DLL files that I have added to a local folder. This is not a good approach and another reason for this question.
Microsoft.DirectX
Microsoft.DirectX.DirectInput
You'll need to change the namespaces to the SlimDx namespaces. At that point, you'll have to migrate some code, as some of the names are different in SlimDx vs. Managed DirectX.
That being said, the basic API calls for DirectX 9 are very similar, so the migration is not too bad once you get going.
I'm a little late to this thread, but I have used SlimDX for a year and I'm nearly but not quite finished translating my embryonic game to SharpDX (because I want to use XAML and a couple other reasons). I highly recommend both, and putting aside SharpDX's advantages (DX11.1, WinRT, XAML, some speed improvements), I would say that SlimDX is as close to managed DX as your going to get, it's equal to SharpDX, without considering those advantages that I mentioned.
I hope the point I'm making is that SlimDX is a closely mapped framework, equal to SharpDX. In that regard, SharpDX can't be recommended alone, without mention of SlimDX. And also I want to make the point that SharpDX will not minimize the migration steps over SlimDX, if that's what you're thinking. They are very similar, more similar than you think if you are of the opinion that you might fail in one and succeed in the other. If you can work it out in one, then you can work it out in the other, they are that much alike. So much alike that I wished they would rejoin as a team and work together on a unified package of frameworks. There is just too much overlap for them to be distinct projects IMO.
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()
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.