Posted: Wednesday, February 12, 1997 3:46 PM
On comp.graphics.api.opengl USENET Newsgroup
I've gotten a lot of email lately about John Carmack's posting on the internet about Direct3D. As Microsofts dually appointed DirectRepresentative for this technology I think it's time I posted a response.
I'll make these points short and crisp so hopefully nobody will miss them.
We've worked with id for a long time on DirectX. Much of the architectures early design and philosophy was driven directly by input I got from John almost three years ago now. Naturally it's disappointing to hear that one of our earliest and most valued customers is dissatisfied, and we're going to attempt to rectify that.
The vast bulk of Johns complaint appears to reduce to the following; "Direct3D is too hard to use/figure out." Yup, he's right. We've done a woeful job of providing sufficiently robust documentation and sample code of Direct3D Immediate mode. If one of the brightest minds in real time 3D graphics can't figure it out, who can? Clearly we've fallen over on that one. Many of the Direct3D titles shipping today, or shipping shortly have been developed with assistance from our developers and our porting lab.
Clearly the API is not simple enough or well documented enough to lend itself to easy learning and adoption, for which we apologize, and I won't bore anybody with excuses. We've been aware of this shortcoming for a while, and have a whole slew of new sample code, and documentation in the works. In the mean time id and any companies with major titles in development have always had an open invitation to our porting lab, or to talk to our engineers if they need to.
We're very comfortable that the Direct3D API can be strongly defended on its technical merits to anyone who understands it, and it's design philosophy. Direct3D's number one purpose in life is to provide a standard driver model for consumer oriented 3D hardware acceleration. It's is not designed to be the ultimate software rendering engine, John will always beat us. It's first design goal was to provide thin fast access to hardware acceleration. That's the number one take away I got from John in those early meetings.. "get your fat API's out of my way and let me at the iron". Direct3D absolutely does this, it may not be pretty, but it does it. It has drivers for every major 3D hardware accelerator shipping, OpenGL does not, and I'm pretty sure that by the year 2000, everybody is going to have 3D hardware and John is going to want to be using that iron. That hardware isn't going to look anything like an SGI pipeline, and OGL is not likely to evolve fast enough as a real-time gaming API to meet Johns needs over time. We're going to add the simpler 3D primitive API's such as draw triangle to D3D IM in the next release to make it easier for people doing quick ports or evaluations to get up and running without the fuss, with the understanding that these primitive API's though easier to use may not provide the versatility and fastest possible performance that tweaking D3D execute buffers will. I'll elucidate further on this point in the random part of this letter.
Okay those are the important points. The points I'm going to attempt to make next fall more strongly in the category of opinion. I gather that some might find my point of view on the subject of OGL vs. D3D interesting so I'll make some further points on that subject and attempt to substantiate them without getting into a "bit head debate".
Don't let the fact that they have the term "3D" in common confuse you. OGL and D3D are designed for very different purposes. Forks and Spoons are both silverware but it hardly makes sense to say that you don't need forks because they're lousy for eating soup, or that spoons suck because you can't eat spagetti with them. Saying you have to always eat with a spoon, or that you're only going to eat soup because you can't figure out how to use a fork is a fair point, but kind of pitiful and should be fixed. Microsoft aggressively supports D3D and OGL as 3D API standards without playing favorites. We see no contradiction in doing so because the API's are designed to satisfy the needs of very different markets. Direct3D is a real-time consumer multimedia API designed to support very fast access to a diverse range of new hardware accelerators. OGL is an industrial strength 3D API designed to serve the needs of high end CAD, modeling, and scientific visualization. It has no driver model because it was designed to support a proprietary pixel accurate rendering pipeline that most consumers won't find in a 200 dollar accelerator any day soon. Nor is there much evidence that it's the kind of hardware consumers would want anyway. Sure there may be some OGL drivers made for consumer iron, but they're not likely to make as good a use of it for games as D3D is. D3D is about direct access to a broad array of consumer 3D acceleration.
It's going to get very weird out there for 3D hardware. The problem of making 3D fast is unsolved. I think we can all agree that it will be a while before we see real-time Toy Story graphics rendered on our desktops.
There are dozens of hardware companies out there trying all kinds of exotic technologies and formulations to find a way to squeeze a few more megpixels out of a 50 dollar piece of silicon. Microsoft certainly doesn't want to stand in the way of their progress, yet at the same time we don't want the PC platform to get so fragmented with divergent 3D hardware designs that nothing works properly. (If you think 2D video card driver problems are a PITA, wait until you see what the 3D hardware does.) Thus the need for a standard driver architecture that is flexible enough to accommodate innovation, yet rigid enough to actually be a standard that gets used.
Think it's easy? Here are a few thought problems for you bit heads out there to solve; How does your real-time game balance it's processing needs across the bus to consistently get the fastest possible performance on hardware that may vary one or more of the following ways;
Are these questions anybody asked in designing OGL?
Does stripping down, or speeding up OGL a bit and touting it as a consumer 3D API demonstrate much comprehension of these issues? How much relevant experience can anybody claim to have at solving these problems? Does all the spoon experience out there translate directly to chopsticks mastery? The consumer 3D HW market is so new that no real experts exist yet, nobody knows how it's really going to evolve.
I dunno, but if you think you've got all the answers then I've got a few questions I'm dying to put to you. In the mean time keep an eye out for the next release of Direct3D which will include the new draw triangle API, new sample code and documentation. I encourage John and everybody else out there to take another look at the next release, and see if it all doesn't start to make more sense.
--
The opinions expressed in this message are my own personal views and do not reflect the official views of Microsoft Corporation