DirectX or OpenGL [closed]

Question

If you were writing the next 3d graphics intensive application in C# (like a 3d modelling and animation software), which one would be a better choice?

If we consider C# as platform independent, then OpenGL seems tempting, but what about the performance, etc?

Since the used language is C#, the performance is pretty crucial to consider.

Edit: You can also consider SlimDX and TAO, OpenTK, csGL, etc too.

Answer 1

DirectX is going to have better video driver support on Windows since it is what MSFT uses to certify cards. We've found OpenGL support is lacking, crashy or plain wrong for cheaper cards on Windows.

Answer 2

I've used both OpenGL and DirectX. I think the performance is pretty similar. I prefer the programming model of OpenGL -- especially its handling of transformations, and direct support of picking operations. I dislike the way MS continues to rewrap the same functionality every time it upgrades the OS, and I think OpenGL protects you from that.

However, both are quirky and you need to spend a good deal of time making sure that it interacts nicely with the hosting application framework, whether Windows or something else.

Answer 3

With OpenGL you can use "DirectX 10 features" like geometry shaders on Windows XP and Linux. Using GLUT it is very simple to get a demo application up and running within minutes.

Answer 4

You will probably want to look into the IrrLicht engine, it has both a C++ and .Net API, and it entirely Graphics API agnostic (meaning you can use the same code to execute OpenGL or DirectX and the programmer wont even have to know which you are using)

You might also want to look into SlimDX, a very fast, lightweight, open source alternative to XNA

Answer 5

If you don't like XNA, you can use SlimDX. Unlike XNA, SlimDX supports DirectX 10.

Answer 6

Performance in managed code, with respect to the graphics subsystem, is not bad. SlimDX pays a slightly penalty over completely native code on each call into DirectX, but it is by no means severe. The actual penalty depends on the call -- a call into DrawPrimitive will be vastly more expensive overall than a call to SetRenderState, so percentage-wise you end up losing a lot more on the SetRenderState calls. SlimDX incorporates a tuned math library that generally performs very well, although you have to be a bit careful with it. Profiling, even with a junker tool like NProf, highlights this stuff very quickly so it's not difficult to fix.

Overall, if we consider generic, completely optimal C++ and C# code doing rendering via D3D, the C# version is probably within 10-15% of the C++ version. That's hard to achieve though; consider how much time you're saving by working in C# which you can apply to higher level graphics optimizations that you probably simply wouldn't have time for if you had to build the entire thing in C++. And even if you managed to get that extra 10% in C++, it'd promptly shrink to 5% within a few months, when a new round of hardware tears through your application code faster than ever. I know what I'd pick -- which is why I wrote SlimDX to begin with.

OpenTK is subject to similar performance characteristics, with the caveat that their math library is rather slow in places. This is an implementation bug that I've discussed with them, and will hopefully be fixed before too long.