My opinion, from the perspective of having converted to D3D from OpenGL.

Ignore John Carmack's infamous rant for starters; it's 15-odd years out of date, refers to DirectX 3, and it was only a year later that he was saying "Direct3D with DrawPrimitive doesn't suck". It's completely irrelevant to any discussion in other words. By all means read it as a historical curiosity, but if you want to get any meaningful info just ignore it otherwise.

OpenGL isn't open source. A lot of people seem to make this mistake (not sure if the OP is heading in that direction); it's not open source, it's an open standard.

Portability. In any non-trivial project the 3D API-specific portion of your code is going to be quite small. You also have decisions to make regarding networking, input, sound, window management, possibly even file IO, etc. Many people when discussing portability say something along the lines of "with OpenGL I can support <long list of platforms>". Oh no you can't. The PS3 doesn't use OpenGL natively, it can use OpenGL through an emulation layer but you get maybe 10% performance; for anything decent you need to use it's native API. Mobile devices mostly don't use OpenGL, they use OpenGL ES which is a quite different beast (very D3D-like in concept and execution actually). Factor in driver quality (which can be quite appalling) and OpenGL's portability advantage doesn't look so hot anymore.

OpenGL is defined as a specification which hardware vendors then implement in their drivers. A lot of this spec actually dates back to the mesozoic era, and covers features that may have been hardware-accelerated on SGI workstations (or that the original writers thought should be added for completeness or correctness sake). Trouble is that in order to be called "OpenGL" an implementation must continue to support these features - through software emulation if necessary. More recent versions of OpenGL have been gradually doing away with this by marking certain features as deprecated, and not exposing them in a "core context".

D3D is more tightly coupled to the hardware. If a feature or format isn't available in hardware D3D just won't expose it. In that sense it's more predictable; if you write D3D9 code for D3D9-class hardware you can have a greater certainty that it will work right on a broader range of hardware. The driver model is simpler too, but comes with some traps that can catch you out (like the infamous D3DERR_DEVICELOST on versions 9 and earlier). Older versions used to look like they were designed by a team of monkeys on LSD; there are still some parts of newer versions that look that way. When it doesn't work it can sometimes fail to do so in style, locking up your machine or resetting your display adapter. D3D's tools are more comprehensive than OpenGL's (PIX, debug runtimes, etc).

Modern versions of both APIs look more similar than different. There's a more or less one-to-one direct mapping between large chunks of them. Modern, well written and highly performing OpenGL code will use exactly the same rendering techniques that D3D has almost always required. This can steepen the learning curve a little as you now need to start planning out stuff like your vertex buffer strategy before you can start drawing anything; no more jumping in and bashing out a few lines of code to get that first triangle on screen.

Portability. In any non-trivial project the 3D API-specific portion of your code is going to be quite small.

Don't underestimate this. Porting an advanced production-class D3D engine to OpenGL, or vice-versa, can be a very time consuming and cost intensive task. If an engine is scheduled for porting to another platform at some point in the future, then this should definitely be taken into account when creating its initial design. Doing so after the fact can be very expensive. In other words, if you plan to port to Mac or to embedded/mobile, don't use D3D. If you plan to port to XBox, don't use OpenGL. PS3 (ie. RSX) is a thing apart.

Mobile devices mostly don't use OpenGL, they use OpenGL ES which is a quite different beast

This is incorrect. Each ES version was always based on a certain OpenGL version. The 4.1 standard specifically mandates full inter-compatibility between ES and OpenGL.

Factor in driver quality (which can be quite appalling) and OpenGL's portability advantage doesn't look so hot anymore.

We recently ported (read: were forced to port) a large 3D application from Windows to OSX. The fact that the original engine was written for OpenGL saved us a tremendous amount of work and money (Win32 to Cocoa was a whole different story though). In fact, OpenGLs portability is one of its primary advantages. As long as we are talking advanced 3D (ie. Intel is out of the picture), then driver quality is not an issue anymore.

D3D is more tightly coupled to the hardware.

Neither OpenGL nor D3D is tightly coupled to the hardware. You'd be surprised how far the low level of modern GPUs is removed from what either of these APIs expose.

[quote name='mhagain' timestamp='1303149641' post='4799991']
Mobile devices mostly don't use OpenGL, they use OpenGL ES which is a quite different beast

This is incorrect. Each ES version was always based on a certain OpenGL version. The 4.1 standard specifically mandates full inter-compatibility between ES and OpenGL.
[/quote]

My point here is that historically ES has always been a subset of full OpenGL. Use any full OpenGL features that are not supported in the ES version you're targetting and you're in rewrite-land. The extent to which you're in rewrite-land varies of course, but in a worst case scenario you may be rewriting your entire rendering backend to go from immediate mode to vertex arrays/vbos. If that's changed in more recent versions then it's a good positive step forward, but for older versions it's certainly not full portability. Portability isn't something that you magically conjure just by using OpenGL - you still have to work for it.

My point here is that historically ES has always been a subset of full OpenGL. Use any full OpenGL features that are not supported in the ES version you're targetting and you're in rewrite-land. The extent to which you're in rewrite-land varies of course, but in a worst case scenario you may be rewriting your entire rendering backend to go from immediate mode to vertex arrays/vbos. If that's changed in more recent versions then it's a good positive step forward, but for older versions it's certainly not full portability. Portability isn't something that you magically conjure just by using OpenGL - you still have to work for it.

And the main point of interest there is the term historical. We're talking about writing a new engine here, in 2011. Or heck, let's even go back a few years. We are not talking about obsolete 15 year old legacy code bases. If your backend is relying on immediate mode, then ES portability is going to be the least of your worries. Vertex arrays have been available for 16 years in OpenGL (yes, 16 years !). To put that in perspective, that was around the time DirectX 2.0 was released. VBOs have been available since 2005, give it a year more for universal driver adoption. The FFP was officially deprecated since OpenGL 3. Portability is a non-issue nowadays. If a developer uses legacy features that may hinder portability, then this is by choice, not by necessity.

D3D10/11 forces this choice, which may indeed be an advantage, as it helps to not propagate obsolete techniques.

Playstation, nintendo, Android, Apple, Linux. Have you ever heard of these? All of these use OpenGL as opposed to Direct x.

Neither Playstation nor Nintendo consoles use OpenGL. They use their own proprietary low level APIs.