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.
Related
How come these "Bible" type books for programming which are supposed to be comprehensive don't mention anything about programming sound or graphics?
My C programming language second edition book came in the mail today by Brian Kerninghan and Dennis Ritchie, and I thought the book was supposed to be comprehensive, but what I first noticed about it is that it is very thin. And it doesn't really seem to talk about much beyond just the basic stuff we have already learned.
So then I thought I would look in my C++ programming book by Bjarne Stroustrop, which is a lot thicker, to see what IT says about graphics and sound, and at least going by the table of contents, in 1200 plus pages, there doesn't seem to be anything on graphics or sound either.
Are graphics and sound some kind of extra subject matter that requires specialty books or something on some specific libraries or something?
Because surely, there must be some foundational stuff on sound and graphics in the core language itself, isn'tt there?
If not, where does one go to start learning about programming graphics and sound?
Sound and graphics are not part of the C or C++ programming languages. The C and C++ standards define only core languages that must be extended to provide other services.
C and C++ are, by and large, abstract programming languages. They specify a few features for input and output, which are subject to interpretation and implementation choices, but they do not specify interactions with devices, including sound systems or graphics displays. They specify features for computing with data and minimal provisions for interactions and storage.
The C and C++ standards define core languages. These core languages are extended in various ways, including:
Providing external libraries that any kind of services, including sound and graphics features.
Using volatile objects to interact with machinery, including devices connected to a processor.
Building more features into the language by supporting additional keywords or language constructs in a compiler.
C++ (and C) does not have graphics libraries as part of its Standard Library
Much to the chagrin of many novice programmers.
The reasons why C++ presently lacks a Graphics Library are varied. There is a proposal for a 2d graphics library to be added to the C++ standard, but it failed multiple times to get added, and as of this year is more-or-less defunct.
There's some writeups on Reddit that try to go into the details of what went wrong, which I'll link below, but I'll summarize the basic issues:
First, the proposal was for functionality that, intrinsically, not all Architectures + Operating Systems could support. Any viable Graphics API needs to have some basic components that can be backed by the Operating System, things like a Surface (something to draw on), a Display, and commands for drawing arbitrary images on that surface and presenting them to the display. Lots of Operating Systems have that: Windows, Linux, MacOS, for example. But many more don't, and trying to build an API where the entire API could be rendered invalid by an Operating System that fails to provide the necessary functionality was troublesome. The philosophy of the Standard Library is that it provides functionality to all compilers that correctly implement it, and a feature that couldn't make that guarantee was inherently unsuitable.
The second problem is that there was virtually no agreement on how the library should be interfaced with. A basic 2D Graphics API like that provided by Java, Python, or (some variants of) BASIC could be implemented in a wide variety of ways, each with quite substantial upsides and downsides, and the authors of the proposal didn't seem to have a coherent vision of how it should be implemented.
In particular, modern graphics is largely a matter of heterogeneous computing, between the ways that DirectX11/OpenGL 4.x try to implement their APIs (more substantially in the former case than the latter...), or the ways that DirectX12/Vulkan represent attempts to get "as close to the metal as possible", and the C++ Standard Library lacks a lot of valuable tools for handling these kinds of functionality.
Tools like std::future might have been sufficient, but in my experience with graphical programming, I'm skeptical it would have been enough, and even if it was, you then have the question of whether you want a Graphics library in your Standard Library that's implemented in such obtuse terms. That's held back the Networking proposal for years, and even that is only getting added in C++23 because there's other library features that are going to support it, like the Executors proposal, which the Networking library is pretty much dependent on.
There's a number of other ways things went wrong, but I'll leave it at those two big ones, since not only do they explain why this specific proposal didn't go anywhere, it also explains why a lot of other ambitious proposals to do the same didn't go anywhere either—including many proposals to add Audio libraries to C++.
So what can you do instead?
For Graphics, you need two things (at minimum):
An API for getting Windows/Surfaces/etc. to display on
An API for generating the images that are displayed
The former can be handled by your Operating System's native windowing api, but you can also use something like QT, GLFW, SDL, or any other api you prefer that's designed for cross-platform compatibility.
The latter can be handled by a good graphics API like OpenGL, or (if you're developing for a Windows environment) DirectX (11-). You could also use Vulkan or DirectX12 if you want to get familiar with the cutting-edge technology, although I'll warn you now that both are far more complex than their predecessors because they don't abstract anything other than the barest of basics, so be aware that it's a much steeper learning curve for those.
For Audio handling, I don't have any recommendations I can personally vouch for (my experience is more limited on that front) but there's quite a few APIs that are specifically designed for that, so just do a little research into what's available.
References:
https://www.reddit.com/r/cpp/comments/89q6wr/sg13_2d_graphics_why_it_failed/
https://www.reddit.com/r/cpp/comments/89we31/2d_graphics_a_more_modest_proposal/
Putting it simply (comment from #NathanOliver): C and C++ have no concept of sounds or graphics.
As you've guessed, graphics and sound are extra subject matter that require other types of books.
Most of these things are abstracted away from the hardware, and are usually OS-dependent.
Take, for example, /dev/dsp on Linux. It's a part of OSS, an abstraction that allows you to play audio. You can interact with it in standard C or C++, it just won't work on all platforms.
For some historical perspective, at least on C:
Once upon a time, the core C language did not even cover I/O to files. The core C language covered the syntax of the language, and that was it. If you wanted to do I/O to files, well, you could include <stdio.h> and call those functions... but they were just external functions in a library, you could use them or not, it wasn't like they were part of the language or anything. (You will probably find language in that copy of K&R you just got saying more or less what I've just said here.)
Now, when the first ANSI C Standard came out in 1989 or whenever it was, it did cover several of the then-standard libraries, so the functions in <stdio.h> (and the ones in <string.h>, and <math.h>, and several others) became a formal part of the language. But that was a pretty significant change.
But there had never been a <stdgraphics.h>, so there wasn't one to standardize. (And of course there still isn't.) And pretty much nobody was doing computer audio in the 1970's, so that had even less of a chance.
(Unix in those early days did have a nice, simple 2D graphics library, <plot.h>, and there might even be a few dinosaurs besides me still using it, but I don't think anyone ever considered trying to push it as a broader standard. Today's GNU libplot is a descendant of it.)
Basically, C never aspired to be a "platform" language like, say, Python. And it's now so well entrenched as a low-level, platform-independent, "systems" language that I'd say there's very little chance that any of these "higher level" functionalities will ever be added to it.
ISO C++ does have a sound and graphics (and input) Study Group:
SG13, HMI & I/O (Human/Machine Interface): Selected low-level output (e.g., graphics, audio) and input (e.g., keyboard, pointing) I/O primitives.
which is currently active (after being inactive).
Audio is probably even more of a mine-field for standardisation than graphics (where, I note, nobody yet has mentioned motion video - see Codecs below). There are at least these levels of abstraction it could operate at (listed from low to high), depending on the application in question:
Raw PCM samples.
Datastreams suitable for audio Codecs (e.g. MPEG layer III, AAC).
MIDI - or other ways of instructing a sequencer on a note-by-note basis
Programatic audio e.g SuperCollider
PCM Audio
Taking the first, this is possibly the most generic and portable. At the very minimum, it requires audio hardware (or, more commonly, a software abstraction) of a double buffer or circular buffer into which output samples are written in real-time to be output somewhere. Lots of parameters here such as sample-rate, channel-count, sample bit-depth, latency, endianness, signed-ness, and whether a push or pull (event-driven) model is used to render buffers of data.
Low-latency audio for professional applications requires real-time threads (and thus, an operating system that provides them), and careful management of system resources.
Successful APIs are CoreAudio (MacOS, iOS only), ASIO, DirectX and whole bunch of Windows APIs (professional software invariable uses ASIO), Jack, ALSA
Codecs
Lots of them are proprietary and patent encumbered. Various web standards have significant difficulties specifying them - and they are far less restrictive than the ISO rules. Not all implementations implement all of them.
MIDI
This is at least fairly standard (although the industry spend nearly 25+ years in replacing it). Twenty years ago, you'd have been driving specialist synthesis hardware with this (pretty much every pre-smartphone era phone and games console had one, mostly made by Yamaha), but these days the sequencer generally drives software synthesisers, and any decent one is proprietary, commercial software. No two implementations have ever sounded the same either, which makes them largely useless for portability.
Programmatic Audio
At this point, you'd be defining an entirely separate programming language.
Conclusions
Good luck trying to standardise any of these - the music software industry has failed repeatedly for decades in its attempts, with much laxer standards bodies.
There's a certain irony that almost all serious audio software is implemented in C++ - often because it lacks any kind of abstractions for audio of its own.
Some background on the variations of graphics support.
Historically, the only supported graphics by computers was ASCII characters. *(Search the internet for "ASCII Art").
Graphics was developed, but had two major flavors: bitmapped and vectored. Some systems had a list of vectors (the math type), and drew those. Other graphic devices used pixels to display images. Even today, some graphic controllers allow you to define your own "bitmap" and have reserved cells (but they don't support line drawing).
The graphics started out as monochrome. One foreground color and one background color, no shades between. This was to simplify complexity and cost. Other features that soon came into being: shades of monochrome and a brightness attribute. The graphics controllers were originally one bit per pixel (either on or off, the "off" being the background color). Graphics controllers then expanded to allow more bits per pixel, monochrome still being the most popular. You could have shades of gray and change the intensity. Some controllers also had bits for "blinking" and other attributes.
With the cost of H/W becoming less and less, graphics controllers started taking on more advanced features: color and bit-blit. Now you could have 4 bits of Red, 4-bits of Green, 4-bits of Blue. This allowed for multiple color and expanding the shading when combining the intensity bit. The graphics controllers started having their own memory and the capability of transferring bitmap data from the CPU's memory to the graphics memory area, often called bit-blit. The controllers advanced to allowing Boolean operations with the blitting (AND, OR, XOR, etc.).
The modern advanced graphics controllers are considered separate computers from the CPU's. Not only do they have their own memory, but they have Cores that can be used by the CPU to perform processing in parallel. Many of these controllers have common algorithms implemented in hardware (such as screen rotation, collision detection). They have multiple buffers so that the CPU can draw into one buffer while the GPU displays another buffer (helps with graphic speed to support animations).
The C and C++ are standards. That is, you should be able to compile a standard C language program to any platform that supports the standard. The issue with graphics, is that there is no standard. Some graphics controllers only support text and bitmaps, and not line drawing. Desktop PCs have various degrees of graphics capability depend on the graphics board plugged into the system. So, there is not much that can be standardized. Also, graphics technology is constantly changing (improving) at a faster rate than the language standards are developed.
Lastly, let's talk about low level programming. To get the most performance from graphics, the code needs to access the hardware directly; sometimes also exploiting features of the processor. Any graphics API placed into the language would have to be abstract to support graphics concepts; and probably not efficient because of the subtraction. The low level programming of the graphics hardware would still exist for performance. The compiler writers are not graphics exports and would either use libraries or compiler for the general case. So many combinations to support (as illustrated in the history section above).
Remember that C and C++ languages are "you only get what you pay for". If I don't use any graphics on my embedded system, I should be able to have the compiler code without graphic support. These languages have a wider audience than other languages that support graphics, like Java.
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.
If i understand correcty, the graphics card are programmed to display 2D&3D graphics and these cards have native functions, but because these functions are obsolete and hard to use, we nou use drivers, that makes the programmers life easier.
Now, my question is that if there are some native graphics card function tutorials and if these are universal, that works on every graphics card or differ from one to another like ASM language does. And if there exists tutorials, can i use C language or C++ or i need to have asm knowledge ?
The way GPUs are programmed (at least the advanced functions) is typically through either MMIO (as in, an address in virtual memory corresponds to a register in the GPU instead of actual DRAM), or more often, through command buffers (as in, a chunk of memory is used to store commands for the GPU, that the GPU reads sequentially.
Now, those commands and registers are very hardware dependent (even within a single hardware vendor): see for example ATI R600 registers. They are not "universal" at all.
Those types of interfaces are what driver developers use to implement the DirectX and OpenGL APIs that typical programs use.
Probably the best source of "tutorial" for that level of programming are the open source drivers in linux.
There's a good reason there are now more standardised ways of talking to the graphics subsystems in computers. Unless you have a specific platform in mind I'd suggest you stick to using the standard API's I.e. go through OpenGL or DirectX.
If i understand correcty, the graphics card are programmed to display
2D&3D graphics and these cards have native functions, but because
these functions are obsolete and hard to use, we nou use drivers, that
makes the programmers life easier.
in a sense yes, although not obsolete, it is all about abstraction.
there are several tutorials on the web, for instance for OpenGL there
is nehe.gamedev.net DirectX has also a number of tutorials, just
use your favorite search engine although OpenGL has the big advantage
of being portable.
Generally you can use either C or C++ and do not need to know any ASM if you
do not have some extreme requirement.
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.
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.