First, and I know this has been said before, it has much better driver support from 3D card companies. There's just no question about it.

Second, its development is geared entirely toward the game development industry. New features are added to Direct3D almost concurrently with their release in consumer 3D hardware. A good example would be the addition of hardware T&L that almost perfectly coincided with the launch of GeForce. All in all, the Direct3D feature set will be expanding much more rapidly that that of OpenGL.

Finally, it really is no more difficult to use than OpenGL. Actually, now that DX 7 is out and there's the D3DX utility library available, I find it considerably more easy to use and straightforward. Setup can be performed in but a few lines of code.

The only benefit that I can think of to using OpenGL is the fact that it is portable across god knows how many platforms. But then again, if you've got the manpower to make a multiplatform product, you'll probably want to use both APIs anyway.

The way I see it, OpenGL was really in interim solution to the need for a good stable 3D API while Direct3D was still in its infancy. Now that Direct3D is surpassing it in functionality and ease of use, there's really no reason to go with OpenGL unless you're concerned with porting your application to platforms other than Windows.

And if you use openGL, you can count on bad
performance on cards that are not fully openGL compatible. ( Like MatroxG200 ).

OpenGL is an extremely well-written, high performance, platform independent 3D graphical API. It is easy to use, powerful, flexible, and well-documented.

As far as features go, OpenGL and D3D/DD are essentially equivalent. I'm fooling around with a 2D wrapper for OpenGL and it is faster than DD as it renders textures using the 3D hardware instead of blitting them.

D3D does have a slight advantage in driver support, but this has been diminishing greatly over the past two years. Any major graphics card will have an OpenGL driver.

The biggest myth I've been hearing from D3D advocates on this message board is that D3D is rapidly adding new features. The reason D3D has been adding this "new" features (stencil buffer in DX5 or 6, T&L in DX7) is becausing OpenGL has had them all along. If board ABC comes out with some new XYZ feature, then they only have to add an extension to their OpenGL driver and developers can use that feature. Meanwhile, D3D developers will be sitting around hoping that the next version of DX supports it.

While Shinkage might that D3D is easier to use, the overwhelming consensus(sp?) is that OpenGL is much better written and easier to use. I'd have to address with the majority based on my first-hand experiences over Shinkage's obvious bias.

I won't even address the ignorance in Shinkage's final paragraph.

Programming is a zero-sum game. I don't win or lose depending on which API you prefer to use. But working with OpenGL has been a pleasure for me so I highly suggest you try it. It allowed me to spend more time learning about graphics and less time worrying about COM programming.

"The reason D3D has been adding this "new" features (stencil buffer in DX5 or 6, T&L in DX7) is becausing OpenGL has had them all along. "

The reason for this is because these features just did not exist in any consumer level graphics hardware (which is what Direct3D is targeted at.) There is no reason to pollute the API with features that are not available.

Features are added to Direct3D usually just before they are available in hardware (such as texture transforms, cubic environment maps, HW TnL in the latest release.) This is due to continued feedback between the Direct3D developers, ISV's, and IHV's.

We're also seeing the API pushing hardware in certain directions. For example, in DX6, DXTn compression was added as a standard compression scheme. It was only available in S3 cards. Now, we're seeing the same compression scheme in Nvidia's GeForce 256, and I believe in 3dfx's upcoming chipsets (in addition to the FXTn compression.) This would not be happening if D3D employed an extension mechanism, and compressed textures were only exposed through an extension.

As for this 2D wrapper that was made in OpenGL that used 3D hardware to do the rendering, the same thing could just as easily be done in Direct3D, so that's not really a good reason to chose one over the other. In fact, with the D3DX utility library Direct3D now has functions designed specifically for this purpose.

One reason I would NOT choose an API is because somebody else uses it. From what I've observed, Carmack had such a dislike for Direct3D when it first came out (and there really wasn't much to like about it), that he wholeheartedly embraced OpenGL. Once you're familiar with one there's really no point in changing, at least right now. Whether or not it is smart business strategy to not fully support OpenGL, past examples show us that many GL driver implementations have been shoddy at best.

The most common thing I see people saying about OpenGL is how they can "focus on the GAME instead of the GRAPHICS". I'll admit that when you still had to use execute buffers and were forced with all sorts of unpleasantness with previous incarnations of Direct3D this may have been true. With DirectX 7, however, I invite anybody to give me an example of how OpenGL is substantially more easy to use than Direct3D. I have so far found none and would honestly like to see what OpenGL has going for it so that I can be more informed in my decision.

While on the surface it may seem that Direct3D has been pushing hardware as of late, I think it is really the other way around. Microsoft surely has meetings with the industry giants (Nvidia in particular it seems) and coordinates with them in implementing in DirectX the features they are planning for their next-gen cards.

As for Kyle's rather insulting comment, simply saying "That's so stupid I don't even need to talk about it," is just a clever way of saying that you either don't have a convincing argument to the contrary or do not want to take the time to explain it. In the former case, just saying nothing would not only serve to not alienate others, but will also not detract from the coherence of your argument. If the case is that you just don't want to fully support your point, then you should not bother posting in the first place.

Nothing like a good argument though. Really gets the mind working.

Oh, and with some final words to the original poster, you can listen to people argue convincingly either way until the universe grows old and dies and still get nowhere. Just try to be impartial and honestly spend a little time getting the basics of both of them down. After doing so you can make an informed decision of your own. That's how I eventually made the decision.

"Being designed for games, it has to keep up with the modern consumer hardware while OpenGL has no such need."
OpenGL keeps up with high-end hardware, which is why it had support for T&L, stencil buffer, etc. long before it was plausible to put these features on consumer hardware.

My 2D wrapper was used as an example because the original poster asked how D3D and DD compared to OpenGL. I was addressing his questions about versatility and functionality.

I agree that one should not use any API because somebody else uses it. But Carmack was already using OpenGL before he tore apart D3D by saying it has "no technical reason for existing."

"Whether or not it is smart business strategy to not fully support OpenGL, past examples show us that many GL driver implementations have been shoddy at best."
You were talking about developers and then jump to IHVs so I am unclear as to what point this was an attempt to make. Games are being made (and have been) with OpenGL as the main (or only) 3D API so I will give the benefit of the doubt that Blizzard (DiabloII), id Software (Q3A), and Bungie (Halo) know more about smart business strategies that us. (And yes I know that a game can only support D3D and will be fine, I just wanted to make that point that OpenGL can also be the main/only 3D API for a game.)

OpenGL drivers are available for virtually every video card now. While this wasn't always the case, it is now else I doubt it would be a "smart business strategy."

Well I guess I will address Shikage's last paragraph now (which I said was ignorant, which differs from stupid.)

"The way I see it, OpenGL was really in interim solution to the need for a good stable 3D API while Direct3D was still in its infancy. Now that Direct3D is surpassing it in functionality and ease of use, there's really no reason to go with OpenGL unless you're concerned with porting your application to platforms other than Windows."
You really think that SGI developed OpenGL so programmers would have something to play with while Microsoft was trying to add all of the features to D3D that OpenGL had while MS was trying to make it easy to use? While a minority have said that D3D is now as easy to use as OpenGL, I will give you the benefit of the doubt and say that it is just as easy to use. So now D3D and OpenGL have virtually the same learning curve and virtually the same features, so that means that D3D is _surpassing_ OpenGL in these categories? This just isn't the case and that is why I said his paragraph was ignorant (ill-informed, or perhaps it was just biased), not stupid.

I do not know all of the reasons that Carmack stated that D3D has "no technical reason for existing", but has to wonder why MS has spent the past few years building D3D and pushing it onto IHVs, ISVs, and developing drivers for it something equivalent to OpenGL when they could have just worked on OpenGL drivers and given developers and consumers the same technology a few years ago.

I realize that for a long time OpenGL was a superior API to Direct3D. The time that this was true, however, has passed. At this point it's really an issue of which interface you like more, and for me that is clearly Direct3D. I will say one thing though, neither API more difficult to use than the other. I've used both of them and can say that they both have their plusses and minuses.

As for geometry blending in hardware, check out the specs for the GeForce. Unless I'm mistaken, support geometry blending is listed as one of the features. I'll admit though, weighted skeletal animation supported natively in hardware and as easy to use as a call to SetTransform does sound too good to be true.

[This message has been edited by Shinkage (edited November 08, 1999).]