Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
The standard model has been that OpenGL is for professional apps (CAD) and Direct3D is for games.
With the debacle of openGL 3.0, is openGl still the natural choice for technical 3D apps (cad/GIS)?
Are there scenegraph libraries for Direct3D?
(Of course Direct3D is windows only.)
D3D makes you pay the Microsoft "strategy tax." That is, D3D serves two masters. One is giving you features and performance. The other is to ensure lock-in to other MS products and the Windows platform generally. This has some consequences for you:
A D3D app won't run on anything but Windows (including Xbox). Maybe you don't think that's important now. But if, down the road, you want to run on Mac, Linux, PS3, future consoles, etc., you may be glad you chose the platform-independent choice.
MS can make some arbitrary decisions. Will the next version of D3D only run on an OS that requires new hardware, is expensive, and lots of people don't want to upgrade to? Will they make some other future decision you don't agree with?
Historically, OpenGL has led D3D in quick exposure of new HW features. This is because there's a mechanism in the standard for vendors to add their own extensions, and for those extensions to eventually be folded into the main spec. D3D is whatever MS wants it to be, with input from vendors to be sure, but MS gets veto power. You could easily be in a situation like with Vista, where MS decided not to expose new HW features to the old DX, and only make the new DX available on Vista. This was quite a headache for game developers.
Now then, this is the flavor of reasons why a "professional app" (CAD, animation, scientific visualization, GIS, etc.) would favor OGL -- apps like this want to be stable for many years, need ongoing maintenance and improvement, and want to run on many platforms. This is in contrast to games, which quite frequently are only on one platform, will be released but generally not "maintained" (there likely won't be a 2.0, an update for another OS three years hence, don't need to support older HW, etc.). Games want maximum performance and only need to work for a short time window and on a fixed number of platforms. If they need to target Windows anyway and D3D is a little faster, that may be the right choice since the negative D3D consequences won't hurt them like it would for a CAD app, say.
Like always, this depends on your situation.
In my experience, currently (2008) OpenGL driver quality on Windows is much worse than Direct3D driver quality. If your situation is such that you can't reasonably demand your customers to always have up-to-date drivers, or tell them to change their graphics cards to the ones that have better OpenGL drivers, then OpenGL is a pretty bad choice. In this case, I'd go for D3D renderer on Windows, and OpenGL renderer on OS X/Linux (if you have to support those platforms, that is).
Having two renderers is not that hard; in my experience working around driver bugs takes much more time than writing and supporting the rendering code paths.
Of course, there are some (specific) situations where D3D just does not have the features needed, e.g. quad-buffered genlocked output; or geometry shader support on Windows XP.
So in short: if you want better drivers on Windows, use D3D. If you don't care about driver quality much, or need features that are in OpenGL but not in D3D, then use OpenGL.
Perhaps you should try an abstraction layer such as OGRE, which lets you switch between DirectX and OpenGL without having to rewrite anything? It also adds a lot of functionality, and isn't game-oriented, but pretty generic.
This doesn't directly answer your question (sorry), but I was one of the original guys working on Direct3D and hehe:
Are there scenegraph libraries for
Direct3D?
Direct3D (nee Reality Lab) used to just be a scenegraph library :-)
Shame that Direct3D Retained Mode isn't shipped anymore...
Direct3D is only available on Windows and XBox. If you plan on targeting Unix or Mac, in addition to Windows, OpenGL is a good choice.
To me, speaking as a graphics programmer in a large CAD company, there are currently three things that retain OpenGL of beeing dropped in favor of Direct3D (10/11) for existing CAD/DCC applications:
Legacy. Most of CAD softwares
are more or less hardly tight to
OpenGL concepts. Rewriting everything
around D3D philosophy is not always
manageable (technicaly speaking
and depending on the ability/willingness of the
company to throw resources at it).
Secondly it could have negative
impacts if something goes wrong
(functionnality speaking and/or
performance wise) and company would just not take the risk of delaying a major release because of an API and architecture switch.
Peoples. Peoples in those old-boy industries
are fairly conservative. They prefer
spending money/time on dealing with
IHVs regarding all OpenGL driver
issues they could have or simply won't recommend using graphics from a specific IHV (e.g. Intel
or ATI).
Plus, I believe that the automotive/aerospace industry customers
like Boeing, Airbus, TMC, BMW, etc
don't care that much of having
Quadros only workstation. Hardware
is still cheap in regard to software
licence prices.
Future trends. With future
generation of processors like Llano,
Larrabee, Fermi and products that
will follow, it's definitely worth
to invest R&D budgets on how to
program and develop new
languages / apis / frameworks for those future hardwares (in term of
graphics as well as non-graphics tasks).
CAD industry has huge
cycles and won't move if not for a truly disruptive technology. So D3D might
just come a bit late for big CAD players (except Autodesk of course which is a particular case).
Not an answer as such but is interesting to note the latest versions of AutoCAD give you a choice between using OpenGL or Direct3D drivers in the "3dconfig" setup option. Fundamentally, AutoCAD is a Windows-only app so it made sense for them to (finally) support Direct3D. See page 15 of this Whitepaper from AutoDesk for more info.
The answer everyone wants to believe is YES but the real answer is, it depends.
About 50% of all hardware out there will not run OpenGL to any reasonable level. To see an example of this read the FAQ for Google Sketchup which uses OpenGL
SketchUp's performance relies heavily the graphics card driver and it's ability to support OpenGL 1.5 or higher. Historically, people have seen problems with ATI Radeon cards and Intel based cards with SketchUp. We don't recommend using these graphics cards with SketchUp at this time. (Hardware ans software requirements for Google Sketchup
So, If you're writing a CAD app and you don't mind telling your customers, "you must have an OpenGL complient video card" then the answer is yes.
If instead you are creating an end-user app (Google Earth for example) then the sad answer is you'll have to write both a D3D and GL version of your app if you want to reach the entire market.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'm a relatively ok-ish programmer, but my main focus has been in application development with C# so far. I have almost zero experience with game development and 3d engines - I've begun reading up on how 3d Engines work in general, e.g. there was a wonderful guide explaining how to develop a very simple software-based 3D engine in C#. Very helpful, but that pretty much summarizes my whole experience with the topic.
Also, I haven't really been working with C++ much so far (even though I'm aware of the basic conceptual differences to C#, and would consider getting up to at least "sufficient" speed in that language manageable).
So anyway, out of pure personal interest, I'd like to play around with developing - or rather, learning how to develop - simple DirectX-based 3d Graphics Engines for educational purposes.
I'm simply interested in the graphics parts (no sound/animation/game states/networking or whatever, only very rudimentary input). Rendering some simple geometry, and then progressively learning how to extend this with more modern shading techniques would be fine.
I've already found some great resources for this. But before I dig into the topic: I know DirectX12 is around the corner, and seeing how much it seems to evolve the system, I'm really not sure if there are going to be many breaking changes to the API. Or in other words: I'm afraid that I start learning DirectX 11 stuff now, and in a few months from now it'll all be useless as DirectX 12 works in a significantly different way, from a programming point of view.
I'm not sure how much of this is already known, or if there are developer previous available to the broader public already. But if its possible to tell already: Would you guys recommend me waiting for DX12, or start with v11 as development will be very similar in the future anyway?
For the record, I know of course that learning DX11 won't hurt in any case. But I'm not in a rush, and if half of what I'd be learning now becomes obsolete in a few months, I'd prefer just waiting until then to slowly get started.
Think of DX12 as "DirectX without training wheels, without brakes, and at the moment maybe without tires".
It will be more than a 'few months' for DirectX 12 to have a rich set of tutorials, support libraries, best practices, rock-solid drivers, and widely deployed support in the operating system on end-users machines. It's "bleed edge" right now, and best consumed by GPU graphics programming experts actively working on titles and engines today who want to make sure it all works.
For everyone else, learn DirectX 11 at least for the next year or so, and possibly longer depending on the needs of your app, your personal skill level, and the focus of what you are trying to learn in the meantime.
What I can say is that learning to program DirectX 11 using the legacy DirectX SDK stuff like D3DX is a dead-end for DX12. Focus instead on DirectX 11 using 'modern' helpers like DirectX Tool Kit and DirectXMath for C++.
Anatomy of Direct3D 11 Create Device
The Care and Feeding of Modern Swap Chains
Direct3D Win32 Game Visual Studio template
DirectX SDK Samples Catalog
DirectX SDK Tools Catalog
Living without D3DX
DirectX SDKs of a certain age
UPDATE: DirectX Tool Kit for DirectX 12 is now available along with some tutorials. That said, it is best to learn Direct3D 11 first as Direct3D 12 is an API designed for graphics experts and is quite unforgiving for newbies. Knowing how to use DirectX Tool Kit for DX11 will naturally map to the DirectX 12 version if you want to go that route.
Most of what you will learn using DirectX 11 will be applicable if you switch to version 12.
In fact, for your purposes, you may not ever need to switch. DirectX 12 essentially trades off ease of use for CPU performance. It also requires Windows 10, so it's going to be more than a few months before it becomes widely used.
DirectX 9 is still widely used for making games, despite its age. I wouldn't recommend it if you're starting from scratch though.
Oh, and whatever you do, don't choose DirectX 10. DirectX 11 can do all the same things, on the same graphics cards and operating systems.
I have seen many graphics applications which primarily support OpenGL. I have also noticed that many of these applications have a -d3d flag which will force them to use the DirectX API instead.
How exactly can a single graphics application use two different APIs but render the exact same result? Surely they would need to add code for both APIs, which is time consuming and a bit of a waste?
The topic of OpenGL vs. DirectX is touchy with many folks, so let me start by saying my intent is to not inflame either side of the "API wars".
If you are talking about general graphics software like CAD, they tend to have a large set of cross-platform targets to support. In these cases, they use OpenGL for systems like MAC and *NIX as well as Windows.
While the developers can use OpenGL on Windows, the 'default' support for OpenGL on Windows is pretty minimal--OpenGL v1.x software only. If you want to use a more full-featured version of OpenGL, you need to have the user install an OpenGL ICD. The quality of these OpenGL ICDs is heavily dependent on each hardware vendor keeping up with the standard, and in the past the OpenGL ICDs for Windows have been tuned for very specific calling patterns for specific applications (read "Doom"). If your application didn't match those patterns, you would sometimes have strange performance problems or hit other bugs.
There has also been a tendency in the video hardware industry for the OpenGL support on Windows on 'consumer-grade' hardware being fairly minimal effort for a few games, while the 'workstation-grade' hardware gets lots of developer resources focused on writing a high-quality OpenGL ICD. In this case, software aimed at workstation (again, read CAD) tends to offer both APIs to cater to the needs of users on both cheaper and more expensive systems. Conversely for games, it's unrealistic to require a $2000+ video card to play to it's often much easier and more robust to use DirectX--unless you happen to the one "must-have" OpenGL only game on the market that the 'consumer-grade' drivers actually work well with.
Using DirectX, particularly DirectX 11 on Windows 7+, works well 'out of the box' for most systems across a wide array of devices from different vendors. Some software developers have found it be far more consistent across different devices and use it as the default when they offer both OpenGL and DirectX. This is why many PC games are DirectX only on Windows. However, if they are already doing an abstraction to support OpenGL for MAC, they may well leave it as an option for users on Windows as well.
For games, abstraction is typical in the rendering engines. To get good performance for a AAA title and hit all the different platforms that matter to them, they typically have to implement multiple versions of their renderer anyhow (Direct3D 11 for Windows Vista+, Direct3D 9 for Windows XP esp. for emerging markets, a variant of Direct3D 9 for Xbox 360, a variant of Direct3D 11 for Xbox One, OpenGL for MAC, specific renderers for PlayStation 3 and/or 4, and for mobile games OpenGL ES). This is usually achieved through an abstraction layer, and then dedicated coders for each platform to marshal the game through to ship taking advantage of what hardware-specific features matter to them. It is not an inexpensive solution, but many large publishers try to arbitrage project risk by offering versions of their content across many different platforms and consider it worth the additional cost.
For indie and small developers, trying to support both OpenGL and DirectX can be a pretty big challenge. It's usually better for them to focus on making a great game for a single platform using a single, well-supported API on that platform. Then if they are successful, they can port it to more platforms by doing the work needed to implement multiple rendering APIs -and- create custom content processing to tailor it to each platform. That said, indie games often don't focus on differentiating on graphics, so the feature & performance trade-offs for using an abstraction layer is less of a problem. It is, however, expensive to test your game across many different devices and do it twice to cover both OpenGL and DirectX.
As I understand GPU vendors defined standard interface to be used by OS Developers to communicate with their specific driver. So DirectX and OpenGL are just wrappers for that interface. When OS developers decide to create new version of Graphic API , GPU vendors expand their interface (new routines are faster and older ones are left for compatibility issues) and OS developers use this new part of interface.
So, when it is said that GPU vendors' support for DirectX is better than for OpenGL, does it simply mean that GPU vendors primarily take into account Microsoft's future plans of developing DirectX API structure and adjust future development of this interface to their needs? Or there is some technical reasons before this?
As I understand GPU vendors defined standard interface to be used by OS Developers to communicate with their specific driver. So DirectX and OpenGL are just wrappers for that interface.
No, not really. DirectX and OpenGL are just specifications that define APIs. But a specification is nothing more than a document, not software. The OpenGL API specification is controlled by Khronos, the DirectX API specification is controlled by Microsoft. Each OS then defines a so called ABI (Application Binary Interface) that specifies which system level APIs are supported by the OS (OpenGL and DirectX are system level APIs) and what rules an actual implementation must adhere to, when being run on the OS in question.
The actual OpenGL or Direct3D implementation happens in the hardware's drivers (and in fact the hardware itself is part of the implementation as well).
When OS developers decide to create new version of Graphic API , GPU vendors expand their interface
In fact it's the other way round: Most of the graphic APIs specifications are laid out by the graphics hardware vendors. After all they are close to where the rubber hits the road. In the case of Khronos the GPU makers are part of the controlling group of Khronos. In the case of DirectX the hardware makers submit drafts to and review the changes and suggestions made by Microsoft. But in the end each new APIs release reflects the common denominator of the capabilities of the next hardware generation in development.
So, when it is said that GPU vendors' support for DirectX is better than for OpenGL, does it simply mean that GPU vendors primarily take into account Microsoft's future plans of developing DirectX API structure and adjust future development of this interface to their needs?
No, it means that each GPU vendor implements his own version of OpenGL and the Direct3D backend, which is where all the magic happens. However OpenGL puts a lot of emphasis on backward compatibility and ease of transition to newer functionality. Direct3D development OTOH is quick in cutting the ties with earlier versions. This also means that full blown compatibility profile OpenGL implementations are quite complex beasts. That's also the reason why recent versions of OpenGL core profiles did (overdue) work in cutting down support for legacy features; this reduction of API complexity is also quite a liberating thing for developers. If you develop purely for a core profile it simplifies a lot of things; for example you no longer have to worry about a plethora of internal state when writing plugin.
Another factor is, that for Direct3D there's exactly one shader compiler, which is not part of the driver infrastructure / implementation itself, but gets run at program build time. OpenGL implementations however must implement their own GLSL shader compiler, which complicates things. IMHO the lack of a unified AST or immediate shader code is one of the major shortcomings of OpenGL.
There is not a 1:1 correspondence between the graphics hardware abstraction and graphics API like OpenGL and Direct3D. WDDM, which is Windows Vista's driver model defines things like common scheduling, memory management, etc. so that DirectX and OpenGL applications work interoperably, but very little of the design of DirectX, OpenGL or GPUs in general has to do with this. Think of it like the kernel, nobody creates a CPU specifically to run it, and you do not have to re-compile the kernel everytime a new iteration of a processor architecture comes out that adds a new subset of instructions.
Application developers and IHVs (GPU vendors, as you call them) are the ones who primarily deal with changes to GPU architecture. It may appear that the operating system has more to do with the equation than it actually does because Microsoft (more so) and Apple--who both maintain their own proprietary operating systems--are influential in the design of DirectX and OpenGL. These days OpenGL closely follows the development of commodity desktop GPU hardware, but this was not always the case - it contains baggage from the days of custom SGI workstations and lots of things in compatibility profiles have not been hardware native on desktop GPUs in decades. DirectX, on the other hand, has always followed desktop hardware. It used to be if you wanted an indication of where desktop GPUs were headed, D3D was a good marker.
OpenGL is arguably more complicated than DirectX because until recently it never let go of anything, whereas DirectX radically redefined the API and stripped legacy support with every iteration. Both APIs have settled down in recent years, but D3D still maintains a bit of an edge considering it only has to be implemented on a single platform and Microsoft writes the one and only shader compiler. If anything, the shader compiler and minimal feature set (void of legacy baggage) in D3D is probably why you get the impression that vendors support it better.
With the emergence of AMD Mantle, the desktop picture might change again (think back to the days of 3Dfx and Glide)... it certainly goes to show that OS developers have very little to do with graphics API design. NV and AMD both have proprietary APIs on the PS3, GameCube/Wii/WiiU, and PS4 that they have to implement in addition to D3D and OpenGL on the desktop, so the overall picture is much broader than you think.
Do the really big games also use Open GL? Or are there some proprietary technologies out there, which can scare Open GL's pants off?
OpenGL and Direct3D both allow comparable access to the GPU.
The "really really really really really really really big games" use one of these, in addition to other non-graphical libraries, plenty of skilled programmers, artists, musicians, game designers, level designers and other staff to create those games "that cost billions to develop".
Feature-wise you can accomplish the same output with either API (OpenGL or DirectX). Several game engines abstract the underlying API from the developer resulting in games which can use either API and are potentially cross platform.
Some examples of this are most of id software (doom,quake,etc) games and any games which use their engine. World of Warcraft also supports either Direct3D or Opengl. Also, several steam/valve games which run on Windows, Mac, and rumored Linux.
OpenGL and Direct3D are the heavy-hitters in the gaming world. Neither scares the pants off the other.
Note, however, that big game houses will use commercial game engines that hide these APIs for the most part.
Most PC games (and xbox360) use Direct3D, but some do use OpenGL.
You can find out more about Direct3D and download it all from Microsoft here...
http://msdn.microsoft.com/en-us/aa937791.aspx
Really big games use a graphics abstraction layer (as mentionned by basszero) since they have to target different platforms that have different APIs:
Xbox 360 : D3D9+
PS3 : libgcm
Vista/Win7: D3D9, D3D10, D3D11
XP : D3D9
OSX : OpenGL
The simple answer is that no, there's no direct alternative to OpenGL that's obviously superior. Direct3D is pretty nearly the only competitor of any kind, and while it's certainly competitive, it doesn't enjoy any major advantage.
At times, Direct3D has had something of an advantage in speed -- it's controlled by Microsoft, who could quickly modify the specification to take advantage of the latest graphics cards updates. At that time, OpenGL was controlled by a multi-vendor Architecture Review Board (ARB). Decisions about new versions of OpenGL took considerable time, and a fair number of vendors seemed more concerned about backward compatibility than taking full advantage of every new trick as quickly as hardware vendors invented them (and nVidia and ATI are sufficiently competitive that they do invent them, and quickly at that).
Since then, control of OpenGL has been turned over to Khronos Group. There's been some controversy about parts of what they've done with the specification (particularly deprecating a lot of features that quite a few people still use) but one thing is open to little question: they're now cranking out new revisions to the specification relatively quickly, so it provides access to the features of even the newest hardware.
Direct3D if you work for Microsoft.
What is the difference between OpenGL and Direct3D? Are they truly different implementations to accomplish the same things (like Java and Mirosoft's CLR [.NET])?
They are very different graphics API's. But it's fair to say they mostly accomplish the same thing. DirectX is probably the API of choice if you are developing a game under windows (or a game for XBOX), and OpenGL is the choice if you want cross-platform support. Mac OS uses GL, as does the iPhone, for example, and many windows games also support OpenGL.
Because OpenGL was developed over a long time and 'by committee', it comes with a lot of baggage - the API has some older options that aren't really relevant today. That's one of the reasons for OpenGL ES; it cuts out all the junk and makes for an easier target platform.
DirectX on the other hand is controlled by Microsoft, and as such it has a more 'modern' feel to it (it's based on COM components, so is highly object oriented). MS often update the API to match new hardware.
Sometimes you don't have the luxury of choice (iphone for example can't run DX). But often it just comes down to personal preference/experience. If your a long-time graphics programmer, you tend to get pretty familiar with both...
Google is your friend in this case...there's a good Wikipedia article contrastring the two libraries:
Comparison of OpenGL and Direct3D
If memory serves, OpenGL was the open implementation before Direct3D came out. Direct3D was then based off of OpenGL...but quickly diverged and became it's own distinct library.
UPDATE
Looks like my memory is shot...
Direct3D was developed independtly of OpenGL.
Direct3D and OpenGL are different API's used to accomplish the same thing.
The major differences between D3D and GL is that D3D is Object Oriented and GL is not.
D3D9 and GLES2 basically have the same features. In fact if you plan on using OpenGL and do not need any GL3 or GL4 features you should base all you code on the GLES2 API(all GLES2 features are in GL2, but not the other way around).
If possible you should always use D3D over GL on windows, as multithreading and driver support is flaky. Take the netbooks for example, they support D3D's HLSL at ShaderModel 2 but don't support the equivalent for GLSL, they only support a fixed pipeline for GL.