Slashdot Mirror
OpenGL Distilled
Martin Ecker writes "Until now, if you were looking for an introduction to the OpenGL graphics API, the "OpenGL Programming Guide" (also known as the Red Book) was your best bet. Now Addison Wesley Publishing provides a new alternative that is easier to digest than the all-encompassing Red Book with its more than 800 pages. Paul Martz's "OpenGL Distilled" concentrates on discussing only the important fundamentals you need to program 3D graphics using OpenGL 2.0 and provides a concise introduction to the most important cross-platform graphics API currently available." Read the rest of Martin's review.
OpenGL Distilled
author
Paul Martz
pages
266
publisher
Addison-Wesley Publishing
rating
8/10
reviewer
Martin Ecker
ISBN
0-321-33679-8
summary
A concise introduction to the OpenGL graphics API
Before going into more detail and reviewing the chapters of the book I have to disclose that I was a technical reviewer of the book before it was published.
"OpenGL Distilled" is aimed at people interested in learning the basics of OpenGL. The reader should already be familiar with programming in C++ and have a basic grasp of linear algebra, in particular vector and matrix algebra. Familiarity with other 3D graphics APIs, such as Direct3D, is an advantage, but not a necessity. The book does a good job of presenting only the fundamental aspects of OpenGL and 3D graphics programming in general and never overwhelms the reader with too much unnecessary detail. The author draws a good line between what to discuss and what is beyond the scope of the book. More advanced features of the API are only mentioned shortly with appropriate references to more in-depth literature. Some deprecated features, such as the feedback buffer, that are no longer commonly used are left out as well. In my opinion an unfortunate omission, is shader programming with the OpenGL Shading Language, which is only briefly mentioned in an appendix. A full chapter introducing the basics would be a nice addition to the book. Until then the reader is referred to the Orange Book, which discusses shader programming in OpenGL in detail.
One thing I highly appreciate about "OpenGL Distilled" is the introductory section of each chapter, which contains a "What You'll Learn" and a "What You Won't Learn" bullet list. This makes it clear what the chapter is about and - more importantly - what it is not about. Especially the latter is mostly missing in other books.
The book has a total of 8 chapters and 4 appendices. The first chapter explains what OpenGL is, talks a bit about setting up a development environment on the most common operating systems to actually develop OpenGL programs, and immediately gets your feet wet with a first simple example program. The chapter is concluded by a whirlwind tour through the almost 15-year history of OpenGL and its predecessors.
Chapter two focuses on drawing primitives, such as lines and triangles, and the various ways supported by OpenGL to specify vertex data. In particular, vertex arrays and vertex buffer objects (VBOs), a fairly recent addition to OpenGL to allow high-performance rendering, are the focus of this chapter. Additionally, a first overview of the OpenGL pipeline that a primitive passes through until it finally ends up in the framebuffer is presented. A more detailed discussion of this pipeline, in particular with regard to coordinate transformations, follows in chapter three. The various coordinate systems used in OpenGL programming, such as object, world, eye, and clip coordinates, are presented and discussed in detail in this chapter.
Now that we can render primitives we need to light them to make them look more interesting. Chapter four sheds some light on this by discussing the lighting and material model used in OpenGL's fixed-function pipeline. The best part of this chapter is the section titled "Debugging Lights", which gives some insights and helpful advice on how to debug OpenGL programs that use lighting. Many other books only describe the features of OpenGL lighting but do not explain common debugging techniques that can be applied when all you get is a black window instead of a nicely lit scene.
Chapter five is about pixel rectangles, in particular how to read from and write to the framebuffer. Some performance considerations are also discussed, which is a good thing since reading from the framebuffer is a costly operation. Again, this chapter concludes with a nice section on debugging techniques. The explanation of the raster position in this section is probably the easiest to understand that I have read to date.
Chapter six is a comprehensive chapter on 2-dimensional texture mapping that also discusses some more advanced applications of the technique, such as light maps and depth maps. Also using cube maps as environment maps is introduced. 1-dimensional and 3-dimensional texture mapping was omitted from the discussion.
Chapter seven deals with detecting the feature set of the OpenGL implementation, in particular, determining the version of the OpenGL specification the implementation adheres to and the available extensions. This chapter also discusses how to retrieve and use entry points for available extensions.
Finally, chapter eight deals with the platform-specific interfaces required to hook up an OpenGL program with the underlying operation system. These platform-specific interfaces are called GLX for Unix, WGL for Windows, and AGL for Mac.
The book has four appendices, which deal with a quick overview of advanced features, best practices, performance-related issues and debugging tips and tricks. Especially the latter two appendices on performance and debugging contain a lot of insights invaluable to programmers just starting out with OpenGL.
The book is printed in black and white throughout. Having some color plates in the book itself would have been a welcome addition considering that the topic is computer graphics. However, you can download some color plates from the books website at where you will also find the source code to the example programs in the book.
In conclusion, "OpenGL Distilled" is an excellent introduction to OpenGL, not only for someone new to 3D graphics programming but also for those that have worked with other 3D graphics APIs in the past that wish to get up to speed with OpenGL quickly. The book omits advanced and deprecated features that would unnecessarily overwhelm a beginner with OpenGL and is a good companion on the way to becoming an experienced OpenGL programmer.
The review author has been involved in real-time graphics programming for more than 10 years and works as a games developer for arcade games. In his rare spare time he works on a graphics-related open source project called XEngine http://xengine.sourceforge.net./
You can purchase OpenGL Distilled from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Before going into more detail and reviewing the chapters of the book I have to disclose that I was a technical reviewer of the book before it was published.
"OpenGL Distilled" is aimed at people interested in learning the basics of OpenGL. The reader should already be familiar with programming in C++ and have a basic grasp of linear algebra, in particular vector and matrix algebra. Familiarity with other 3D graphics APIs, such as Direct3D, is an advantage, but not a necessity. The book does a good job of presenting only the fundamental aspects of OpenGL and 3D graphics programming in general and never overwhelms the reader with too much unnecessary detail. The author draws a good line between what to discuss and what is beyond the scope of the book. More advanced features of the API are only mentioned shortly with appropriate references to more in-depth literature. Some deprecated features, such as the feedback buffer, that are no longer commonly used are left out as well. In my opinion an unfortunate omission, is shader programming with the OpenGL Shading Language, which is only briefly mentioned in an appendix. A full chapter introducing the basics would be a nice addition to the book. Until then the reader is referred to the Orange Book, which discusses shader programming in OpenGL in detail.
One thing I highly appreciate about "OpenGL Distilled" is the introductory section of each chapter, which contains a "What You'll Learn" and a "What You Won't Learn" bullet list. This makes it clear what the chapter is about and - more importantly - what it is not about. Especially the latter is mostly missing in other books.
The book has a total of 8 chapters and 4 appendices. The first chapter explains what OpenGL is, talks a bit about setting up a development environment on the most common operating systems to actually develop OpenGL programs, and immediately gets your feet wet with a first simple example program. The chapter is concluded by a whirlwind tour through the almost 15-year history of OpenGL and its predecessors.
Chapter two focuses on drawing primitives, such as lines and triangles, and the various ways supported by OpenGL to specify vertex data. In particular, vertex arrays and vertex buffer objects (VBOs), a fairly recent addition to OpenGL to allow high-performance rendering, are the focus of this chapter. Additionally, a first overview of the OpenGL pipeline that a primitive passes through until it finally ends up in the framebuffer is presented. A more detailed discussion of this pipeline, in particular with regard to coordinate transformations, follows in chapter three. The various coordinate systems used in OpenGL programming, such as object, world, eye, and clip coordinates, are presented and discussed in detail in this chapter.
Now that we can render primitives we need to light them to make them look more interesting. Chapter four sheds some light on this by discussing the lighting and material model used in OpenGL's fixed-function pipeline. The best part of this chapter is the section titled "Debugging Lights", which gives some insights and helpful advice on how to debug OpenGL programs that use lighting. Many other books only describe the features of OpenGL lighting but do not explain common debugging techniques that can be applied when all you get is a black window instead of a nicely lit scene.
Chapter five is about pixel rectangles, in particular how to read from and write to the framebuffer. Some performance considerations are also discussed, which is a good thing since reading from the framebuffer is a costly operation. Again, this chapter concludes with a nice section on debugging techniques. The explanation of the raster position in this section is probably the easiest to understand that I have read to date.
Chapter six is a comprehensive chapter on 2-dimensional texture mapping that also discusses some more advanced applications of the technique, such as light maps and depth maps. Also using cube maps as environment maps is introduced. 1-dimensional and 3-dimensional texture mapping was omitted from the discussion.
Chapter seven deals with detecting the feature set of the OpenGL implementation, in particular, determining the version of the OpenGL specification the implementation adheres to and the available extensions. This chapter also discusses how to retrieve and use entry points for available extensions.
Finally, chapter eight deals with the platform-specific interfaces required to hook up an OpenGL program with the underlying operation system. These platform-specific interfaces are called GLX for Unix, WGL for Windows, and AGL for Mac.
The book has four appendices, which deal with a quick overview of advanced features, best practices, performance-related issues and debugging tips and tricks. Especially the latter two appendices on performance and debugging contain a lot of insights invaluable to programmers just starting out with OpenGL.
The book is printed in black and white throughout. Having some color plates in the book itself would have been a welcome addition considering that the topic is computer graphics. However, you can download some color plates from the books website at where you will also find the source code to the example programs in the book.
In conclusion, "OpenGL Distilled" is an excellent introduction to OpenGL, not only for someone new to 3D graphics programming but also for those that have worked with other 3D graphics APIs in the past that wish to get up to speed with OpenGL quickly. The book omits advanced and deprecated features that would unnecessarily overwhelm a beginner with OpenGL and is a good companion on the way to becoming an experienced OpenGL programmer.
The review author has been involved in real-time graphics programming for more than 10 years and works as a games developer for arcade games. In his rare spare time he works on a graphics-related open source project called XEngine http://xengine.sourceforge.net./
You can purchase OpenGL Distilled from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
My only complaint is that the binding broke in a couple of weeks, and I had lost the receipt. So hold onto it.
The review here links to B & N, but it seems that Amazon has it rather cheaper.
Ok, the first chapter sounds like a waste, you can easily find this kind of info online or in the docs. I wonder how much of the 266 pages is taken up by useless stuff such as printing the contents of the source code that is on the CD included (assuming a CD is included). This is my biggest peave with tech books, reprinting the source code to fill space, reprinting online docs to fill space and giving you intro information on how to program.
This is the sort of book that may become quite useful in the future. Over at OSNews there have been some rumors that the AMD/ATI combo will be releasing a high-quality OpenGL 2.0 implementation to take advantage of the many OpenGL-related advancements there have been for X recently. Supposedly they want to be at the cutting edge of technologies like Xgl, Compiz, glitz and so on.
I really don't know if this is idle speculation or there is some basis to it, but it is something interesting to consider. Perhaps nVidia should step up and release an OpenGL 2.0 implementation before AMD/ATI manages to. Last I checked, the implementation provided with the nVidia drivers for Linux was for OpenGL 1.4.
I'm reading this right now, and it is substantive and helpful. The downside is that it can get rather terse at times, without as much explanation as I felt was deserved. I suppose that's why they called it, "distilled". :)
Anyhow, the bulk of the book is not for the faint of heart. Be dialled when you read this, you're not getting any hand-holding.
It's interesting the review above was written by one of the technical reviewers of the book, the result being more of an overview than a pure objective review (with positives, negatives). Or maybe I'm asking too much.
This sounds like an interesting book to read over coffee or something. But does it cover that weird thing where the RGB values are 16-bit in some places and 24-bit in others? That really confused me in the past.
Quake/Doom , Unreal Tournament, etc... use OpenGL. Many workstation apps use it too.
Why was this modded as a Troll? His point is valid, and there doesn't seem to be any referrer-link badness in there.
Speaking as a seasoned software engineer, I can honestly say that for Win32 development, there is no reason to ever use OpenGL, because it sucks balls compared to DirectX. Anyone that objectively evaluates both APIs can tell you this...
I would like to see DirectX ported to AIX, Solaris, HPUX, all the common Unices... and maybe a VMS port too.
PFFFFFFFFFFFfttttt LOL that's liek nutin does gaymz donnt any1 play k
lol @ u for tryin to maek opgl look god
Oh wait.. did you say Quake an Unreal Tournament? The two biggest 3D engines in the gaming market? Fuck. I feel like a moron right now.
The mask slips off, and your opengl overlord stands revealed as none other than Cthulhu!
You lose your mind an instant before losing the head that contained it, as you are rapidly, twitchingly devoured, sycophant.
those are all made by two companies maybe he should have said "lets pretend anyone except id Software and Epic Games use OpenGL."
OpenGL is what you use to learn and try out 3D Graphics, not necessarily for public releases. You do this because it's free to use, unlike DirectX. DirectX does kick the shit out of OpenGL, but OpenGL is free. I thought slashdot loves things that say "Open" in their names?
Not to mention SketchUp, recently re-released by Google, AutoCAD & every other major package for architects (one called ArchiCAD uses openGL to accelerate the display of 2d linework), and any 3d modelling program (MAX, MAYA, Blender). Hell, there is even an openGL renderer for Flash somewhere.
Maybe the parent was thinking about StarFox for SNES?
Dammit Otto, you have lupus.
Stop spreading these myths about OpenGL not being supported on Vista. OpenGL is will remain alive and well for Vista.
It's true, most users of OpenGL today aren't game developers. We're doing far more serious and practical work. What we're talking about here are medical imaging, military simulations, petroleum exploration, and advanced CAD design.
OpenGL likely powers the design tools that were used to develop many of the components in your computer, your vehicle, your cell phone, and your television. OpenGL is used by the simulation software your father's doctor uses to track the spread of your father's penile cancer. OpenGL is used in the process of locating the oil which becomes the gas you pour into your car.
OpenGL is used all around you. You're mostly just oblivious to it, since your world doesn't extend outside of Halo 2.
What you won't learn in chapter 1
I'm in the market for a new computer, and I'm going to be writing games for it.
What's the deal with developing with OpenGL on linux at the moment? Last time I tried (2002 maybe?), there was something called Mesa, another thing called DRI or some such, another thing called GLX. It all got a bit confusing. I ended up using cygwin for a bit, then finding something else to do.
Is it the case now that I can just 'apt-get install opengl-devel' and have stuff just work?
Why, God, why did I burn my mod points yesterday modding up "...welcome our new overlords" and "3. ??? 4. Profit" jokes?
I badly want them back so I can mod this whole thread OT.
Yeah, because the "lack of popularity" means something is useless. Because DirectX will be the defacto standard on lin... oh wait no it won't. Well it might be on OS... nope nope, won't be there. Maybe on the Wi... wait nope, not there either. Or on the PS3. Or on the DS. Or on the PSP.
In fact, I have a funny feeling there's a lot more titles using "other" standards than DirectX. Maybe it's not quite as dominant as your myopic little view of the world leads you to believe. In fact, a lot of independent titles and teams swear by OpenGL, SDL, and OpenAL. The next (very sexy) generation of X servers will slap OpenGL under the hood to do all their whizbang effects that make Vista look tired and old already.
Diversity is good. Don't be a quivering sphincter and shit on it when it shows up.
Save yourself some money by buying the book here: OpenGL Distilled. And if you use the "secret" A9.com discount, you can save an extra 1.57%!
OpenGL is a open source 3D graphics rendering standard, sort of like direct x without sound and I/O support.
Mesa is a open source linux OpenGL compatible library, you will find that other venders make Linux openGL compatible librarys like ATI. Example if you install the Official ATI linux video drivers you also get their version of openGL library along with it.
DRI (Direct Rendering Infrastructure) this open source video driver system allows direct access to the video card which in turn improves OpenGL preformance.
GLX an improved x-windows openGL interface for applications
cygwin an linux style interface for windows
Wise men speak because they have something to say, Fools because they have to say something!!!!
If movies taught me anything its that The Red Book is NSA Trusted Networks and doesn't fit on shelves.
Obviously Unreal Tournament, the Quake/Doom series, Warcraft III, and that obscure game known as 'World of Warcraft' don't use OpenGL. Unpopular games like Half-Life/Counterstrike don't use OpenGL. There are no games for the Gamecube, and there will be no games for the Wii or the PS3.
And obviously all serious visualization work isn't done in OpenGL.
Go back to your cave, troll.
Blizzard games use OpenGL too. Virtually all of their games (at least back to the point when they changed their name to Blizzard) have been developed with cross-platform in mind, and they usually release games on PC/Mac hybrid CD's. All of the 3D games Blizzard has put out (Diablo 2, Warcraft 3, WOW) fully support OpenGL. The Windows version will use Direct3D by default, but you can also make it use OpenGL if you want to. Doing this isn't particularly obvious (especially to someone who's never used a command line, as there's no option in the game to do this)...you just have to start the executable with the -opengl switch. This obviously makes running the Windows version under Wine/Cedega much easier (since Direct3D emulation isn't nearly as good as native OpenGL support). You don't lose ANY features by switching to OpenGL rendering (in fact for the Mac versions this is the only option)...the only way it will cause any problems for the Windows version is if your video driver has poor OpenGL support. Poor OpenGL support will become more common with Vista, as Microsoft is crippling the OS's OpenGL support, and they will probably encourage video card manufacturers to do the same.
If I understand the question, I think you want to try GLUT. If you are feeling adventurous, try OpenGL enabled SDL. http://www.libsdl.org/
I like OpenGL, but my one problems is the lack of ease it gives for Win32 Programmers. I know it is cross-platform, but to program a opengl app in linux and win32 are totally different, so what's the point in developing a OpenGL app if the audience you intent on targeting is small(I.E. Linux)? Why not just setup for MS's DirectX which will obviousally win your apps much more support.
N. A. Stuart
There is a devel package for mesa that provides basic OpenGL bindings (since Mesa is a software OpenGL-compatible library) and headers. It provides a (roughly) complete OpenGL 1.3 implementation (I'm pretty sure it's 1.3 with extensions), and while not explicitly licensed, is widely considered a standard implementation. It's everything you need to develop OpenGL apps.
Of course, nVidia and ATi drivers provide their OWN OpenGL libs and headers, nVidia's implementation being a full-blown version 2.0, and it includes headers and libs for development.
DRI, as I understand it, is part of the driver interface for X that supports hardware acceleration of OpenGL.
GLX is the X11-specific bindings that handle creating windows and contexts for GL output. GLX is to X11 what WGL is to Windows.
If you install mesa-devel (or whatever your distro calls it - on Gentoo, it's part of the full deal), you'll have everything you need to start hacking yesterday.
grey wolf
LET FORTRAN DIE!
If you're going to be writing games and want them to be easily ported to other systems (Win and MacOS, and others), besides learning OpenGL, look at SDL and OpenAL. You can use SDL for a standard way to initialize your graphics hardware (OpenGL doesn't deal with that, it assumes the hardware is already set up for graphics) and user input (joysticks, etc) on different operating systems. OpenAL is a standard cross platform library for audio.
Correct me if i'm wrong, but don't Unreal Tournament, Quake, Doom 3, and many other games use OpenGL? Plus, technologically, OpenGL is leaps and bounds ahead of DirectX - ATI and nVidia are looking to the OpenGL specs to improve their cards, and DirectX kinda says, oh we like that new feature, let's copy it.
How well does the book cover the subject of stereoscopic 3D?
BTW, for anyone reading this -- does anyone know how to get Google Earth to do stereoscopic 3D?
Another book covering the same niche as the story subject is http://www.amazon.com/OpenGL-Primer-2nd-Edward/dp/ 0321237625/sr=8-2/qid=1156983388/ref=sr_1_2/104-82 07668-6969568?ie=UTF8">OpenGL: A Primer from Prof. Angel. I like it as a companion to the Red Book, it's like hearing the same material presented by a different teacher in a different way (so those on amazon's site who complain about overlapping material, miss the point). If I had to pick one, I'd definitely keep the Red Book, but this one earns its keep on my shelf. And it's much more portable, if you like studying in the coffee house or library.
The Really Slick Screensaver collection. Blender. Jahshaka. Quake (all versions). Doom 3. Warcraft III/World of. Halflife / Counterstrike. The GameCube. The Wii. (supposedly,) the PS3. Bryce 3d. Anything by Silicon Graphics. Bindings for every language on every platform under and out of reach of the sun.
Yeah. Completely unpopular. Please do me a favor and remove your lips from Mr. Ballmer's rear end long enough to post coherently when on Slashdot.
110100 1101000 1101000 1100110 0 1101111 1101000 1100011 1
*sniffs the air*
Smell that? That's the sweet, pungent smell of GP's sarcasm.
Take it in, boy, take it in.
110100 1101000 1101000 1100110 0 1101111 1101000 1100011 1
DirectX does kick the shit out of OpenGL, but OpenGL is free.
How ignorant, and blind, can a person be to make this statement? DirectX, is probably... why even try to explain how much crap DirectX is. You're definately a consumer. In the most negative sense of the word.
DirectX, will, and you mark my words, NEVER be of enough quality to be used in CGI REALISM. OpenGL can, generate very realistic renders... so realistic, it's used in all major film FX.
The reason why OpenGL games aren't as good looking, is becuase it targets the consumer; you know, morons like yourself. Who, do not have the hardware to render heavy duty OpenGL sequences. Before you jump up and down, your lame GeForce 9999999 is crap and only geared towards the most common 3D calls for GAMERS and CONSUMER LEVEL 3d applications. There is NOT ONE consumer level card, even for a scant 400-500 dollar hot release, that has hardware acceleration for 100% of ANY 3D API... even DirectX.
Now, what Microsoft did, was compose a bunch of wiz-bang API calls into DirectX, while OpenGL programmers are left to write their own. OK, does this mean DirectX is better? The only thing "better", is time for development. As far as seeing an EXACT same effect used in ALL DirectX games???? Anyways... with all the exposure of the white collar sweat shops of EA Games and other such game development houses... no wonder a lot of games on the shelf were developed under pure management and they chose DirectX and Windows as their primary market. However, a few of those programming houses actually know a thing or two about 3D programming, actually have the resources and clout to take the time to do something RIGHT. idSoftware for one, and what API do they chose? Not DirectX! And, there's a reason why. Becuase it f*cking sucks, I can't put it anymore blatant than that.
I'm just finishing this book right now, and I think it's IDEAL for a new OpenGL user. You will need to know the basics of matrices and vectors and their application (but don't worry, there's no eigenvalue problems or matrix inversion here). Aside from C/C++, though (classes and C++ features are only used in a limited sense in the book), it's the only prerequisite.
The book goes out of its way to cleanly show you how to use the fundamental processes in OpenGL without teaching you any out-of-date methods or descending into irrelevant detail. The now-dying glBegin() and glEnd() is replaced with vertex buffer objects, and it's a refreshing sight to see just how terse and relavent this book is. You simply get a clean-cut how-to of using OpenGL to achieve your ends. Any time you might need to go beyond the clear and simple and start using the rarer features of OpenGL, the book points you onto the resources you need. It's fully aware, and makes you aware, that you're not getting the whole picture on OpenGL, just the most relavent picture as of right now.
One of the best things, though, is that this book is a breeze to read. I've read it in a couple of weeks casually, and worked through a couple of my own example programs. The speed with which I've learned OpenGL is really enjoyable. I now know how the main features work, and I'm free to concentrate on using them. The GL Programming Guide really can't compete with this, and is far too long to serve as a tutorial. Buy this book instead, work through it, and then turn to the Programming Guide once you need to start looking beyond OpenGL Distilled.
As a final point, this book may be terse and focused, but it certainly doesn't skip relavent details. The final chapter holds a full discussion of stencil shadows and depth-map shadows, which although somewhat complex, are truly relavent in an age where realtime shadowing is becoming the norm in many applications. For a book this short to teach such a rich and usable amount of information without becoming confusing is incredible, and I would not hesitate to recommend it to anyone.
As a balancing factor, though, there are one or two sections that could definitely be explained more clearly. In these cases, though, there are sufficient resources available online that you shan't find yourself in trouble, even if the book is at fault.
Well said, brother!
Registered Linux user #421033
Full disclosure: Paul is a friend of mine, and I helped proof this book too.
In all seriousness, this is an excellent book. Paul wrote this book to fill a serious need -- an updated, quality OpenGL book for this age. So much of what is in the canonical texts is no longer important (geometry by Begin/End), and they won't cover the new recommended practices (VBOs, Vertex Arrays, etc).
On a personal level, Paul is one of the most generous and helpful programmers I know. I owe him lots of beer for all the advice he has provided. He also participates in the open source OpenScenGraph project:
http://openscenegraph.org/
a high-performance 3D toolkit for Windows, Mac and Unix/Linux, used in hundreds of open source and commercial simulator, game and 3D visualization projects (including my company's NatureView Express tool http://3dnature.com/nv.html -- plug plug!)
-- There is no truth. There is only Perception. To Percieve is to Exist.
Mod parent troll, doesn't even consider debugging or that DirectX is a more full package and that he should be talking about Direct3D. Also mentions iDsoftware where he probably means John Carmack who said that he would probably use Direct3D nowadays if he didn't have to port.
-]Phreak Out[-
This is somewhat correct, but wrong in a big way. Before the takeover, the OpenGL ARB had to vote on features to make it into the spec, disclosing any patents they might have relating to a feature. This made things slow. You can see how long it took for OpenGL 2.0 (which started as 1.3!) to come out.
I hear the process for DirectX was more along the lines of MS asking what features card manufacturers wanted and then they were quickly put into practise. Often there was a reference rasterizer before hardware was in the people's hands.
-]Phreak Out[-
G3D! (http://g3d-cpp.sourceforge.net/)