OpenGL 2.0: Chasing DirectX 311
MJ writes "Is
OpenGL 2.0 All That? Hopefully you will be able to answer that yourself after reading this article from XtremePcCentral. They have cool looking leap frog graphics with lots of arrows and a quote from John Carmack, what else could
you ask for? Robert Richmond does a great job of delving into this
subject. Carmack says, 'The implementation went very smoothly, but I did run into the limits of
their current prototype compiler before the full feature set could be
implemented. I like it a lot. I am really looking forward to doing research work
with this programming model after the compiler matures a bit. While the shading
languages are the most critical aspects, and can be broken out as extensions to
current OpenGL, there are a lot of other subtle-but-important things that are
addressed in the full OpenGL 2.0 proposal.'"
OpenGL 2.0 (Score:4, Funny)
You can tell by the numbers!!
Re:OpenGL 2.0 (Score:2)
Re:OpenGL 2.0 (Score:3, Funny)
You need to compile a humor mod...
Re:OpenGL 2.0 (Score:5, Funny)
By version 20, it should be good enough to simulate virtual 3D porn environments - thus justifying the name DirectXXX.
Goobers (Score:2, Interesting)
Does anybody else get the impression that "MJ" works for "XtremePcCentral"? I'm seeing a lot of this astroturfing on Slashdot lately, and it's lame. If you want to drive traffic to your site, buy an ad.
Re:Goobers (Score:5, Informative)
Nah, I just got the impression that MJ just cut'n'pasted directly from HardOCP [hardocp.com]. Word for word. I kid ye not.
Re:Goobers (Score:2)
If the article is interesting to the
OpenGL is vital for Linux (Score:5, Interesting)
Re:OpenGL is vital for Linux (Score:5, Informative)
Remember that Apple and the Mac OS rely on OpenGL for graphics. That combined with continued interest in OpenGL on the PC side for CAD and the like -- not mention Carmack and Co. -- should keep OpenGL around as a viable alternative.
Re:OpenGL is vital for Linux (Score:2)
It's is an open secret that graphic chips makers hesitate to fully support OpenGL as that'd adversely affect the long term relationship with MS - you know how bad it'd sound.
We couldn't blame MS for that, they are talking about business here. Game consoles play even dirtier games in this regard.
Re:OpenGL is vital for Linux (Score:5, Insightful)
Your sentance above is unclear, but I understand you're saying that Apple's OpenGL has better hardware support than x86? You do realize that Apple's video chips come from the same IHV's?
Re:OpenGL is vital for Linux (Score:2)
It doesn't matter on which hardware platfomr Linux will have success. Mac/PPC? Even better!
The question is: can Linux/PPC take an advantage of Apple's hardware?
Re:OpenGL is vital for Linux (Score:3, Insightful)
I think you make a good point. For the most part I agree with you, but I'd make one little change: Linux needs something like DirectX to succeed. Whether or not it is OpenGL is not crucial. The problem with OpenGL is it doesn't keep up with the features of new cards the way DirectX does.
Linux needs a developer who's on top of the game like MS is. The smart thing to do would be to mimick DirectX as much as possible, make it easier for a PC game developer using DirectX to port their game over to Linux. Let's be frank: With as few gamers running Linux as there are today, ports of existing games is all they're gonna get. Might as well work to make that transition easier.
Re:OpenGL is vital for Linux (Score:5, Insightful)
Not many games keep up with the features of new cards, so OpenGL doesn't have to be bleeding edge to run them. The reason there aren't that many games for linux isn't that OpenGL is dated.
Besides, most good games offer both OpenGL and Direct3D renderers. The rendering is only a small part of a 3D game and it is not that difficult to provide alternative renderers.
And frankly, who cares if "Sunny Garcias Pro Surfing" runs on linux or not.
The smart thing to do would be to mimick DirectX as much as possible, make it easier for a PC game developer using DirectX to port their game over to Linux.
Dear god please no. The goal of OpenGL should be to provide an excellent api for realtime 3d programming, not to mimic Direct3d. If any Direct3d programmer understands 3d concepts well enough, porting to OpenGL should present no difficulty whatsoever. And vice versa.
Re:OpenGL is vital for Linux (Score:3, Insightful)
From what I understand the non-"immediate" mode of Direct3D is much higher level than what OpenGL provides in its current form. This IS important because not all game developers have the time or brains to hand craft an entire engine technology for each game like Carmack does. They have to rely on a prebuilt and high level library that makes their job easier (and rightly so). So OpenGL has to step up to the plate and also provide some high level functionality. This also has the upside of becoming hardware independent and more easily customizing the backend to the hardware (these shading languages, etc.).
Any way that was the perception I got last time I looked at Direct3D...which was a LONG time ago
Re:OpenGL is vital for Linux (Score:5, Insightful)
Linux already has its own DirectX-like wrapper system. It is called SDL and it is multi-platform, unlike DirectX. It allows you have "low level access to a video framebuffer, audio output, mouse, keyboard, and joysticks across a wide variety of operating systems." (from the libSDL page). With that, it supports plugins and addons, and a full rewrite is going into SDL 2.0 to make it much more robust and flexible. It is a proven and powerful method of producing games on Linux, and is nowadays seen in most commercial apps.
Honestly.. I hate to say it, but you seem to be doing nothing more than talking in circles. I honestly wonder how some of you people on Slashdot make these things up. While I agree that there aren't nearly as many gamers that use Linux, there is still a userbase- and a growing one. As for your suggestion of mimicing DirectX- that's already been attempted. It's called WINEX. It's a layer between a layer between a device. Work is being done on attempting to create an Open DirectX-like library and API, but don't count on it working out. It only provides a wrapper for existing OpenGL devices right now. There is a reason that Microsoft changes DirectX every year. It isn't just about adding new features. Backwards compatibility is shady at best.
Re:OpenGL is vital for Linux (Score:5, Informative)
FYI - WineX uses OpenGL to emulate DirectX! OpenGL is indeed critical.
The Raven
Quick bitching about WineX please (Score:2)
The rpm installed (--nodeps) on my Gentoo system without a hitch. Then you type 'winex
Warcraft III under WineX is quite impressive, as is Black And White - even though it has some 'issues' on my system.
Of course native Linux games are preferable. But in the meantime, WineX Rocks!
All in the name (Score:5, Interesting)
Re:All in the name (Score:2, Interesting)
The thing is that JC thought that DirectX was severely over-complex to do anything worthwhile. In OpenGL he got the exact same thing done as DirectX, but with less code, and less stuff that got in the way. He summed it up nicely. DirectX is crap because it is too complex. OpenGL is quite simple and it'll help you get stuff done.
Also, OpenGL is a real industry standard, as where DirectX isn't. OpenGL is cross-platform, as DirectX isn't.
Re:All in the name (Score:2, Informative)
Re:All in the name (Score:5, Informative)
The cross-platform one is interesting if you're in the games business, since of the commercially viable platforms (i.e. Windows PC and the consoles - even if both of the Mac owners buy your game you'll never recover your costs), OpenGL is supported on precisely one of them, whereas Direct3D is supported on two (PC and Xbox).
Re:All in the name (Score:5, Interesting)
I realize that Direct3D has gotten better, but still, it's going to be a tough job for MS to totally finish off OpenGL. It's well rooted into spaces other than gaming, like CAD/CAM and VR research. And if MS tries to patent it away, that will never work, because of prior art.
I think MS's stance toward OpenGL is neutral. I'd say that if somehow Direct3D would die off, MS would embrace (and probably extend) the OpenGL standard.
What 3D library does, say the PS2 and the Nintendo console use? Their own in-house one? I'd guess OpenGL, because it's available on many platforms, and it's portable. And don't forget the wealth of documentation and example code that's out there for OpenGL. It'd save a lot of time training-wise. It's a wise choice if you do console development on a workstation and if you can just cross-compile so it'll work on the console. Other than the X-box (which is just a IA32 machine on funny hardware), DirectX is indeed only available on 2 platforms.
I'm not a console-developer though, maybe someone who develops 3D-action games for consoles that are not X-boxes could comment?
Re:All in the name (Score:3, Interesting)
AFAIK the PS2 and GC both have proprietary graphics libraries (and in the PS2 case, not much of a library at all).
There's certainly a lot of sample GL code out there, but the bulk of it is on the basics, which is really pretty simple in either API. The complex stuff often revolves around vendor-specific extensions in GL, about which there is considerably less material widely available, certainly not significantly more than for Direct3D.
Re:All in the name (Score:2)
Of course. You are absolutely right. But I thought it deserved a mention.
As for the availability of examples and advanced stuff out there, check out NeHe [gamedev.net]'s website, which shows you what neat stuff is possible with just the "standard" OpenGL 1.2. Very clear examples, and very portable code. Easy to understand as well. If someone ever wants to get started with OpenGL, that is one place to start.
Re:All in the name (Score:2)
Re:All in the name (Score:2)
Gamecube's API does have many similarities to OpenGL hwoever, much more than to say, DirectX. Really, this comes from the fact that ATI, who bought ArtX, who used to be part of SGI, used to use OpenGL I'd imagine...
Re:All in the name (Score:4, Informative)
Re:All in the name (Score:3, Informative)
PS2 - (sarcasm) What! PS2 uses a 3D library?! (sarcasm off)
You write your *own*, or use a middleware solution: RenderWare, NetImmerse, etc. Sony only provides a bares bones library with basic functionality that sometimes the samples use.
GameCube - I forget the name of the API. It is OpenGL like, but not the same. I'll post a follow up when I get into the office, since I'm not the Gamecube programmer at work.
X-Box: A bastardized version of DirectX 8.0/8.1
> Their own in-house one?
Only if you got 6 to 12 months to write & optimize T&L code, Clipping, Stripping, Smart Batching, Advanced Filters, and a Mesh/Bone animation system!
> I'd guess OpenGL, because it's available on many platforms, and it's portable.
Guess again. I don't know of ANYONE shipping titles using OpenGL on the consoles.
X-Box - Why would you waste time trying to get OpenGL to work, when DirectX 8+ allows for your PC (DX) engine to be ported over in *days*. You can use OpenGL for testing, but you have to go thru some hoops to get it to work (when I heard last year)
GameCube - No need, since the existing API works just fine.
PS2 - While there is PSGL (OpenGL clone), OpenGL will NEVER run at full speed on the PS2 - due to missing *hardware* functionality: i.e. no stencil buffer, limited (some say broken) blending modes, etc. You need to go straight-to-the-metal to get optimal performance out the machine.
> It's a wise choice if you do console development on a workstation and if you can just cross-compile so it'll work on the console.
Ha! If it only were that easy. Sorry, I don't mean to sound pesimestic but I've seen way too many "the bug only happens on the PS2, but not the GameCube, X-Box, or PC. Argh" this year.
PS2 - The hardest parts are making efficient use of the 7 cpus, managing the 4 Megs of Video Memory (4-bit and 8-bit palletized textures help), managing a couple hundred megs of audio on disc thru the 2 Megs SPU (Audio Chip), smart streaming on the 2 Meg IOP, and keeping the VU's and GS well fed.
GameCube - making good use of A-RAM on the GameCube, etc. Again, not the gamecube programmer.
But yes, you're right. If you write your own middleware, the game code doesn't have change (much) for the various consoles.
I really hope OpenGL 2.0 revitalizes OpenGL, because it's a real pleasure to use, but I don't see OpenGL support on consoles at least until PS3, X-Box2. (Haven't heard anything on GameCube2)
Cheers
Are you drunk? (Score:3, Informative)
OpenGL on playstation2 [dataplus.co.jp]
OpenGL on the Xbox [extremetech.com]
This is a great quote from the article, turns out OpenGL is superior than Direct3D on the XBox.
Re:Are you drunk? (Score:3, Interesting)
As an Xbox games developer, I can assure you that there is no OpenGL support on Xbox. I can also assure you that I'm happily using the feature he talks about via Direct3D.
Re:No GL, no Doom 3. Simple. (Score:2)
Even if MS did provide some kind of GL-like wrapper for Xbox, just to appease John Carmack (which, honestly, I don't think is as big a deal as you're making out, given the different market in console games) they'd be unlikely to offer it to developers in general simply because they wouldn't want to chew up resources supporting the fucker.
Re:Are you drunk? (Score:2)
Re:Are you drunk? (Score:2)
It's a novelty and nothing more, like getting gcc to run on a Palm. There is not one single PS2 game that is written using OpenGL.
Re:Are you drunk? (Score:2, Interesting)
It just doesn't map onto the architecture... and you pay the penalties.
Re:Are you drunk? (Score:2)
A John Carmack interview here [ign.com]
Excerpt:
IGN Xbox: What do you think are the chances of Microsoft actually supporting OpenGL on the Xbox, and why?
JC: Last I heard, Nvidia was going to be providing OpenGL for it.
--
Also, found this about the Gamecube, near as I can tell it supports OpenGL directly.
http://www.elecplay.com/news.html?article=5917 [elecplay.com]
Carmack's post (Score:2, Informative)
The comment can be found here [slashdot.org]
Re:All in the name (Score:5, Insightful)
This won't happen too often. DirectX is crazy feature rich. In fact, overly so for some
You need to realize the OpenGL isn't an open source project. You can't add more stuff to the API if you find that it's lacking. The reason is that you can't add your new functionality to the hardware, which is the whole point in using OpenGL in the first place. So, you still have to wait for the next version of OpenGL to come out, and graphics-cards manufacturers to build cards with it in mind.
Whether coding in GL or DirectX, if the library doesn't do something you want, you have the exact same options: wait for the next version, or hand-code your functionality from fundamental functions.
This is one spot were DirectX has a big advantage over OpenGL. DirectX is designed by only one party, rather than a big committee of different companies who want different features. As such, DirectX has a much faster development cycle, and gets improvements quite often. The last big improvement to OpenGL was released in 1998, version 1.2. Four years is a long time in the world of 3D graphics.
Re:All in the name (Score:2)
um... (Score:2)
# of revisions != how good it really is now.
Old DirectX was craptacular, we all agree. new directX is getting there. *shrug*.
Re:All in the name (Score:2)
This is one spot were DirectX has a big advantage over OpenGL. DirectX is designed by only one party, rather than a big committee of different companies who want different features. As such, DirectX has a much faster development cycle, and gets improvements quite often. The last big improvement to OpenGL was released in 1998, version 1.2. Four years is a long time in the world of 3D graphics.
This is not true at all. OpenGL has a clear extension mechanism and the Architecture Review Board approves vendor extensions frequently in the period between spec revisions. In fact, a large component of the spec revisions is the inclusion of ARBextensions in the core spec.
Re:All in the name (Score:2, Interesting)
Periodicly, the ARB goes through and blesses some extensions, making them official. They're still optional in terms of compliance to the standard, but the ARB blessing catalizes a commonly supported API for each feature.
Eventually a new version of the spec is rolled, and usually the majority of changes were already seen as ARB extensions before.
So, OpenGL has managed a steady evolution. Where it has been slower in reguards to directx is in iterations of revolution. In five years DX went from being bizarre to being very similar to OpenGL, changeing the fundamental philosophy of the API design in the process. Dictatorships allow rapid broad changes like this. OpenGL has not done that so well, which is what the OpenGL 2.0 initiative is a response to.
Re:All in the name (Score:5, Interesting)
Ah, but what if you can add new functionality to the hardware, because you are the manufacturer? With DirectX, nothing changes -- if the API doesn't support what you want, it won't until MS says so. With OpenGL, you can expose new hardware functionality through an extension. Programmers can use your hardware's new features immediately, unlike with DirectX.
So, you still have to wait for the next version of OpenGL to come out, and graphics-cards manufacturers to build cards with it in mind.
This is the exact opposite of what actually happens. In reality, manufacturers build cards with new features and expose them through extensions. Then, in the next revision, the new functionality may be folded into the standard API. The hardware leads the API, rather than trails, without sacrificing the ability to use the hardware immediately.
This is one spot were DirectX has a big advantage over OpenGL. DirectX is designed by only one party, rather than a big committee of different companies who want different features. As such, DirectX has a much faster development cycle, and gets improvements quite often.
OpenGL gets an improvement whenever a vendor has an idea for what new trick they'd like their hardware to pull. Yes, it takes them some time to agree on what the next official version of the API should look like, but that doesn't slow the development and acceptance of new features a bit. Vendors can innovate as much as they want, without waiting for a central body to approve and support their innovation -- that is a big advantage.
As opposed to DirectX... I just can't see how being dependent on a single outside vendor to support your hardware's features is an advantage.
Four years is a long time in the world of 3D graphics.
Yes, and in those four years we've seen the development of hardware T&L, texture compression, pixel and vertex shaders... And OpenGL has not wanted for one of them.
Re:All in the name (Score:5, Insightful)
But what happens when DirectX doesn't do what the programmer wants/needs it to do?
The programmer is screwed with either API. Sure the hardware company can extend either API to its heart's content, but that doesn't help a programmer who needs a feature right now.
The development process isn't too different with DirectX--Nvidia had some whiz-band ideas so they talked to Microsoft. DX 8.0 was released. ATI had similar functionality for their hardware, but didn't agree with Nvidia. They went to MS and DX 8.1 was released. Microsoft talked to them both and is going to release 9, itegrating 8.0 and 8.1 features. The architechture review board for OpenGL does the same thing.
Microsoft doesn't make all the decisions for the industry and cram it down the industry's throat. MS talks to all the relevant companies (hardware and software) as part of the feedback loop for DX. Microsoft/Nvidia's Cg language that was in the news a while back is an example of that. The advantage is that Microsoft has tightened the feedback loop so its turnaround time is less.
When are people going to understand... (Score:5, Informative)
OpenGL does not provide any other of DirectX's functionality...
Re:When are people going to understand... (Score:2, Insightful)
Re:When are people going to understand... (Score:3, Insightful)
When was the last time Joe Home-User *needed* to download DirectX?
These days, when Joe wants to play a computer game, it'll install DirectX for him if he doesn't have the required version.
Re:When are people going to understand... (Score:5, Informative)
Re:When are people going to understand... (Score:2)
Even John Carmack, who has been critical of parts of DirectX in the past (e.g, Direct3d), uses other parts of DirectX in his projects. For example, in the windows versions of Quake3 (and Quake3-derived games), DirectInput is used. A OpenGL/DirectInput combo is actually quite common.
Re:When are people going to understand... (Score:4, Informative)
Sure, but that why there's OpenAL [openal.org], not to mention OpenNL [hawksoft.com] (now called HawkNL) and its extensions, and OpenIL [imagelib.org] (now called DevIL). Wasn't there an open input layer too? They've gotten hard to find now that so many of them changed their names (due to pressure from SGI? See the OpenIL site!)
Anyway, there's also SDL [libsdl.org], and for that matter OpenML [khronos.org]. Both are far more functional than OpenGL alone.
In summary, if you want a cross-platform DirectX alternative, there are options. You just have to know about them or search them out.
GL/DX or C/C++? (Score:3, Interesting)
Re:GL/DX or C/C++? (Score:4, Informative)
(full quote, for the parent is at Score: 0)
It shouldn't make any difference. Since C++ is a superset of C, you can use OpenGL just fine with it (and if you can't find one of the 092384092389 C++ wrappers for OpenGL out there, you can always wrap it up yourself). At the same time, COM has always been available to C code as well as C++ code, so you can use DX in C as well (it's just very ugly). In either case, I don't think the native language of the library should make a difference -- COM is supported by many languages (some requiring that the COM object support the IDispatch automation interface, but I believe DX already does that, and if it doesn't you can wrap that yourself or find bindings that somebody has already done), and thus DX is available (C, C++, VB, Delphi, Java, and all of the managed code langauges). OpenGL is written in C, which means it's easy for developers to write bindings for other languages (C++, perl, python, ruby, etc).
The moral of the story is that any properly designed library will be available across languages, so don't let the library tie you into a language you don't know or like.
Re:GL/DX or C/C++? (Score:3, Informative)
g_pDP->Initialize( NULL, DirectPlayMessageHandler, 0 );
To make the same method call from C, use the following syntax. The conventional name for the vtable pointer is lpVtbl.
g_pDP->lpVtbl->Initialize(g_pDP,NULL, DirectPlayMessageHandler, 0);
As for your question: no, I doubt it. The C vs. C++ thing isn't really a problem since nearly all modern compilers support both. They'd choose OpenGL over DX (or vice versa) for different reasons. If you were to build a 3-D engine, you could expose a C or C++ API using either library under the hood.
Conection is Dragging (Score:4, Informative)
Future Look: OpenGL 2.0 Preview by: Robert Richmond Preview Date: November 11, 2002
OpenGL has been a primary component of three dimensional rendering technology since its inception in 1991. OpenGL is implemented in a wide variety of applications, ranging from professional design software to multimedia presentations to interactive games. Currently available as version 1.4, OpenGL has proven to adapt with the evolution of graphics hardware, though it's age is becoming starkly apparent as compared to Microsoft's latest DirectX D3D technology. In hopes of revitalizing the decade old standard, 3Dlabs recently offers a new approach outlining the features of a possible OpenGL 2.0 revision. The concept of a proposal as compared to a standard needs to be clearly defined for the purposes of this preview article. The OpenGL 2.0 topicalities presented here are based upon a discussion text and early developmental engineering from 3Dlabs. Many vendors usually submit discussion texts and/or proposals during the OpenGL ratification process, then an appointed governing committee will analyze the various aspects of the given information before reaching an agreement about the final published standard. Since the OpenGL 2.0 development process is still in finalization stages, the information presented within this text will likely undergo multiple changes before a final OpenGL 2.0 specification is adopted for widespread industry use.
About 3Dlabs
3Dlabs has been a long-time contributor to the OpenGL community by providing advanced 3D hardware solutions to the professional marketplace. 3Dlabs graphics accelerators are commonly utilized for computer-aided design, multimedia development, and special effects rendering. 3Dlabs technology can also be found in many non-PC devices like military aircraft and personal cell phones. 3Dlabs is a wide market corporation with operations currently in Alabama, California, Massachusetts, Texas, Washington, Germany, Japan, and the United Kingdom.
OpenGL 1.x Limitations
The bulk of graphics development was centered on 2D rendering until 1997. The only areas of computing utilizing 3D technologies before this time were generally in the extremely high-end professional markets, such as CAD or virtual reality. The mid-90's release of desktop-oriented 3D accelerators like 3dfx's Voodoo or Rendition's Verite ushered in the concept of affordable 3D graphics for most mainstream PC users. Nearly a half decade later, desktop 3D video cards now include options like cube mapping, hardware transform/lighting, and programmable vertex/pixel shading. The OpenGL interface has evolved along with these new rendering features, but today's OGL 1.x does have substantial room for improvement as the next generation of video chipsets could finally outpace the capabilities of this venerable standard.
For example, the popular OpenGL 1.3 API suffers from several major limitations, especially in regards to extending the base programming interface to include additional rendering options. The base OGL 1.3 specification documentation is approximately 284 pages of programming conventions and theory, while nVidia's extension documentation needed to implement options like per-pixel shading is well over 500 pages in length. The concern over efficient programming is clearly apparent once one factors in proprietary extensions from other corporations like ATI, Matrox, STMicro, and the vast number of other companies currently offering OpenGL compliant drivers.
The age of OpenGL 1.x is the primary contributor to these limitations, as hardware has evolved at such a rapid pace over the past few years. System that were once considered to offer high performance only a couple of years ago are now entry-level configurations at best. The rapid development of hardware plays a significant role, as many manufacturers are adding OpenGL extensions without any real inter-corporate centralization in order to release products by usually grossly misrepresented retail availability deadlines.
Worst yet, it appears OpenGL is following nearly the same development paradigm as DirectX. DX7 was the last fixed-function D3D interface, with the current DX8 standard being devised around poorly coordinated implementations of programmable rendering options. DX8 offers v1.2 programmable options, while DX8.1 offers a slightly improved v1.4 programmable feature set. This development schedule can wreak havoc on developers and hardware engineers. For example, the GeForce-3 supports v1.2, but the Radeon 8500 supports v1.4. In can be expected that programmers will likely opt for the lowest common denominator when coding, thus it is suspect whether some of these staggered options will ever be included in software released in the near future. Only with the release of DirectX 9 does Microsoft plan to offer a hardware independent programmable interface.
Some developers have proposed extensions to OpenGL 1.x to add programmable rendering options including various extensions which may not be compatible with hardware from another manufacturer. Efforts are also being established to institute a generalized extension set for programmable shading, though these are still largely hardware dependant, thus they will not work with all OpenGL implementations. The goal of 3Dlabs' OpenGL 2.0 initiative is to create an uniform standard with a hardware independent shading language that functions with nearly all OpenGL compliant graphics accelerators.
OpenGL 2.0 Envisioned
3Dlabs hopes to address several key issues with its OpenGL 2.0 approach. OpenGL needs to evolve into an easier to code interface format with optimizations for memory management and timing control for increased performance potential. Another issue to be addressed is how to deploy generalized programmable shading routines which are hardware independent. The overall predominate concern is maintaining complete backwards compatibility with OGL 1.x standards while retaining the functionality of the new standard's advanced rendering options.
3Dlabs has received positive support from many facets of the graphics engineering community. Universities like Stanford are already hard at work on extended OpenGL rendering routines which support some of the v2.0 conventions. Most hardware manufacturers and software vendors are also expressing overwhelming support, as an improved OpenGL standard could lead to better graphics and performance with less development overheard and greater product turnaround times. Regardless of those involved, 3Dlabs is working towards a future OpenGL 2 interface without any imposed royalties or operating system limitations in hopes of establishing a wider market base.
OpenGL 2.0 Explained
The 3DLabs approach is to first extend software through utilization and public promotion of certain OpenGL 2 standards, then gradually move code towards a "pure" OpenGL 2.0 environment. However, unlike DirectX 8, all OpenGL rendering conventions should be available for those seeking a pure OGL implementation at release, instead of staggering the releases in various subset revisions. As stressed earlier, the ultimate final goal is to reach a streamlined programming interface which offers hardware independency.
Each of the programmable processor pipelines (software and/or hardware) essentially eliminate and/or replace a significant portion of current OpenGL conventions. The programmable vertex processor replaces the current options for transform, lighting, normalization, texture coordinate generation, and fog rendering. The fragment processor replaces the current operations for smooth shading, texture access, texture application, alpha testing, and pixel transfers. The pack/unpack processor included capabilities for flexible pixel formatting during memory move operations to create a coherent and consistent stream of pixel data to the rendering pipeline. The clear benefits of these programmable options are increased performance and image quality by removing the dependence upon fixed functions of static T&L pipeline routines. The associated rendering conventions for each of these advanced routines are unified through a comprehensive C-based programming language with special detail added for vector and matrix processing operations.
3Dlabs also implements a new data buffer mechanism to be utilized for enhancement of the programmable rendering interface. The buffer is used to enable multiple-pass fragment programs with full stream processing support. Usage examples include multiple outputs from a single fragment routine, intermediate result storage, multi-spectral imaging, and acceleration of back-end rendering by reducing the time needed for read-back of floating-point images by the host bus. Additionally, the buffer space is accessible through either spatial or FIFO memory operations.
Today's OpenGL 1.x provides no real direct control over when or where objects are stored or deleted within the memory address range. OGL 1.x also provides no direct control over memory copies or address fragmentation. 3Dlabs plans to implement a new management routine to allow for improved timing control over memory operations. The OGL 2.0 proposal sets policies and priorities for all datasets with timing estimates provided for each task. Additionally, all pinned policy operations allow the application to control memory store/delete and packing operations.
John Carmac's Opinion
"Given the good first impression, I was willing to go ahead and write a new back end that would let the card do the entire Doom interaction rendering in a single pass. The most expedient sounding option was to just use the Nvidia extensions that they implement, NV_vertex_program and NV_register_combiners, with seven texture units instead of the four available on GF3/GF4. Instead, I decided to try using the prototype OpenGL 2.0 extensions they provide.
The implementation went very smoothly, but I did run into the limits of their current prototype compiler before the full feature set could be implemented. I like it a lot. I am really looking forward to doing research work with this programming model after the compiler matures a bit. While the shading languages are the most critical aspects, and can be broken out as extensions to current OpenGL, there are a lot of other subtle-but-important things that are addressed in the full OpenGL 2.0 proposal.
I am now committed to supporting an OpenGL 2.0 renderer for Doom through all the spec evolutions. If anything, I have been somewhat remiss in not pushing the issues as hard as I could with all the vendors. Now really is the critical time to start nailing things down, and the decisions may stay with us for ten years.
A GL2 driver won't give any theoretical advantage over the current back ends optimized for cards with 7+ texture capability, but future research work will almost certainly be moving away from the lower level coding practices, and if some new vendor pops up (say, Rendition back from the dead) with a next-gen card, I would strongly urge them to implement GL2 instead of proprietary extensions."
John Carmac Lead Programmer ID Software
Final Thoughts
OpenGL 2.0 is still in its development stages, though 3Dlabs does offer some insight into the new features needed for this aging standards to maintain acceptance within the graphics marketplace. As noted earlier, the concepts and ideas presented here are only preliminary at best. The information gathered for this article was obtained through various discussion overviews published by 3DLabs and associated companies. It appears 3DLabs and other developers are steadily moving forward with development of a new and exciting OpenGL standard that strives to offer the best compatibility with sustained performance across the widest variety of hardware configurations available.
they modded the post not the person (Score:2)
As you rightly point out, redundant is appropriate so what's the problem?
Moderation is, conceptually, to categorize the pages on behalf of the reader; not manipulate the ego of the poster.
problem with opengl (Score:4, Interesting)
Re:problem with opengl (Score:3, Offtopic)
And the extensions let them expose feature of their hardware that the spec currently doesn't support. That's good for you (who get the features sooner) and good for the company (who can sell their cards based on those features sooner). And the best of those features get folded into the spec next revision. I'm not sure how you can call this a "problem".
It's a lot better than ATI not being able to sell the nicest features of their card because the owner of the software they depend on hasn't put out a release that supports those features yet -- and of course you not being able to -use- those features.
Re:problem with opengl (Score:2)
Success (Score:5, Informative)
vs. DirectX (Score:5, Interesting)
BTW: what is the status on the MS patent issues? Anyone know?
What a great article... (Score:5, Informative)
Come on, they basically copied the documents that have been at 3Dlabs' site for over one year, copied the graphics that were in those documents, and can't even spell "Carmack" right (they spelled "John Carmac", twice).
If you want the real deal, go here [3dlabs.com].
RMN
~~~
A good ways towards "All That" (Score:5, Interesting)
Note that the OpenGL 2.0 spec is a proposal by 3dLabs [3dlabs.com]. As you may have seen on Slashdot a while back, their latest graphics cards are designed for this kind of extensive programmability (trying to raise the bar significantly over today's programmable vertex shaders.) Essentially, they're working on making the graphics chip (or VPU as they like to call it) more of a general-purpose processor, capable of running complex programs (kind of like a CPU.) Recognizing that few people would want to develop applications that are tied to a specific brand of video card, they have written a public spec (which should then, hopefully, be supported by other hardware manufacturers.) In theory, I see OpenGL 2.0 as hailing a pretty exciting new generation of graphics technology.
For anyone who's interested, I suggest you check out the overview of the proposal, available here [3dlabs.com].
spelling. (Score:5, Funny)
Can' wai fo tha doo thre gam to com ou. Mayb i wil suppor openg 2. i w ar luck.
Wh can' peopl proofrea thei shi?
Re:spelling. (Score:2, Interesting)
Like many will point out (Score:5, Insightful)
It's short sighted thinking that got us into the situation that were in now, where one nasty law-breaking company wields its power with an iron fist and wants to crush any potential innovators before they even have a chance to compete.
Who knows what other grahpics programming languages have been or will be quashed because of Microsoft? The only reason OpenGL even survived is that it was mature to enough not to be blown away be those crappy early versions of DirectX.
illustration of shaders? (Score:2)
Images that can illustrate this would be especially nice.
Re:illustration of shaders? (Score:5, Informative)
- App send OpenGL vertex data.
- Vertex data gets rotated, translated, and scaled according to the modelview matrix.
- The scene is project onto the screen using projection matrix.
- Triangles are constructed from projected vertex data.
- Triangles are broken down into scanlines, and color values are stored in the framebuffer based on a specific combination of material color, lighting, and texture information.
The OpenGL 2.0 programmable pipeline is different. In addition to the features of the fixed function pipeline you have additional steps.
- Verticies, instead of going through a fixed set of transformations, instead go through a shader program. The shader program manipulates the position of the vertex much more flexibly than a fixed transformation. For example, a vertex program could make the verticies of a flag move to simulate the waving of the flag in the wind. It can also do similar things for water or cloth.
- Pixels, instead of being colored according to a fixed formula involving material, lighting, and textured, are also run through a mini program. The pixel shader (also called fragment shader) is presented with a set of inputs (texture data, lighting information, material color) but has the freedom to access other data as well as do its own computations. This allows advanced effects like more realistic lighting, bump-mapping, basically anything you can program.
- Instead of having fixed conversions between different data formats, you have what are called pack/unpack processors. You can run mini programs on the pack unpack processors to flexibly translate between data formats without losing the benifet of hardware acceleration.
All of thse features allow far more advanced effects than what is possible with a fixed pipeline. For a look at exactly what effects are possible:
http://firingsquad.gamers.com/hardware/r300/pag
NVIDIA has a pixel shader design program you can check out.
Doom III uses pixel shaders for dynamic shadows, among other things.
A game called AquaNox uses pixel shaders extensively for water effects.
Unreal Tournament 2003 uses pixel shader as well.
DirectX (Score:5, Interesting)
DirectShow - Gives you a unified media framework. Allows plugins to be written independent of program, and allows programs to use any installed plugins. The code for something like this exists (or soon will) in the Linux world, in the form of gstreamer, aRts, mplayer, and xine, but unfortunately, the latter are not one framework, but several. In particular, it infuriates me that there are codecs that mplayer has support for that xine doesn't, since Xine has KDE interface and mplayer doesn't.
DirectPlay - A high level networking API. DirectPlay is independent of the underlying protocol, and encapsulates high level networking concepts like meeting places and session management.
DirectMusic - This is something that Linux really doesn't have, to my knowledge. DirectMusic allows the composition of dynamic soundtracks using a powerful MIDI engine. I know MIDI sounds like a throwback to the past, but several modern console games have taken to using it to allow in game music to reflect in game events.
Re:DirectX (Score:5, Interesting)
I'm not sure about some of those, but I do know that there is OpenPlay [apple.com], an alternative networking API. Here's a quote from the site:
Re:DirectX (Score:2)
Re:Consoles are still space constrained (Score:2)
Re:Disc consoles are access-time constrained (Score:2)
Re:DirectX (Score:2)
theory vs reality (Score:5, Insightful)
What I always thought that was cool about the idea of DirectX was where you could in theory make certain calls (API or direct) that would stay the same while the actual logic behind the action could be updated and upgraded. Of course this is really the promise behind COM, but was advertised as being the main thing to shout about for DirectX.
However, in reality each release pretty much rewrites the entire system. And since you cannot mix versions then you are forced to either rewrite your entire calling routines or just suck it up and go with the older version (and be hammered by kiddie/poser reviewers).
If OpenGL would apply the lessons from this and build a multilayered (or rather multilayer-abstracted) interface system so that components can be enhanced or changed without requiring a rewrite of code (or at least a major one). What is the point of API's during times in which capabilities change so much if they are outdated in 6 months? I guess what really confuses me are the trollish kiddies that will parrot things on the order of, "why do you need API's, shouldn't you do real programming and blah blah blah?" Well the typical and rightful response to this is "and I suppose that not only are you programming in binary, but more importantly you are not using a text display but are in fact using a dial or manual switch system..."
Basically I see little difference between the number and variety of cards that are released on one day (lateral) as ones released over time (vertical). Yet what happens is that some new card enables a new rendering toy _OR_ some better method of implementing an existing method is released and we break the system. Don't get me wrong, a system like this is not easy to implement... at least not from scratch. However, based on the history and patterns (lessons learned if you will) from attempts up to this point, there should be a good place to start. There are definitely differences between changes like mono sound to multi-channel suround 3d sound with cherries on top, and that of different methods of shading for 3d rendering. After all, anyone who can fly an aircraft can fly any aircraft that follows the common interface, regardless of using prop or jet or whatever. Sure, there are differences in various controls but anyone who has flown very much knows the similarities are more than the differences in terms of operations. This even includes changes from dials to digital, etc.
This makes it harder to build reusable libraries and engines. That equates to two things: higher prices for your games, longer times to release (and flakier games because of the non-learning aspect of marketers and publishers) and of course underutilization of available hardware and technology. Three reasons? NOBODY EXPECTS THE SPANISH INQUISITION!
Maybe the day will come where there can be very generalized, abstracted toolsets/API's that are common to all major functionalities (sound, 3d graphics, 2d graphics, etc) that can be safely drilled-down as low as the programmer wants to go. Pipe dream at this point, but then again so were most of the things we use today at one time.
Re:theory vs reality (Score:5, Insightful)
Forgive me, but do you have the vaguest idea what you're talking about?
This is the whole point of OpenGL. It also pre-dates DirectMess by ten years or so.
Silicon Graphics, the creators of OpenGL, originally wrote APIs for their workstations that were more or less hardware-specific. Every time they came out with a new machine, a new version of the API would come out, and all the apps would have to be re-written. After the fifth time or so, SGI got enough flak from both internal and external developers that they decided to write an abstract API such that the client software wouldn't know or care about the underlying implementation. This gave SGI the freedom to take features previously implemented in software and drop them into hardware, and the application would work without recompiliation.
The same principle applies to this day. Back when the first version of GLQuake was released, 3D-accelerated cards had one -- perhaps two -- texturing units. They also didn't have hardware transform and/or lighting. Now, graphics cards typically have four texture units, hardware transform and lighting, vertex shaders, full-scene anti-aliasing, etc. etc. etc. But that old copy of GLQuake id Software released five years ago still works. Heck, it even works better now. Which is the whole point.
What you describe already exists. It's called OpenGL, and it works.
Schwab
Games are good but... (Score:5, Interesting)
To me, OpenGL lacks really good object-picking algorithms, has problems with coplanar geometry (lines on top of polygons, for example), and poor typography support.
Personally, i would like to see OpenGL move towards being more suitable for general purpose displays, which would allow easier implementation of things like Apple's OpenGL accelerated windowing system.
I know that programmable pixel shaders etc. are useful, but why does OpenGL not specify things like raytraced and radiosity lighting models, along with voxel primitives, and features for window and page oriented output of arbitary geometry (including support for true curves/surfaces etc.) ala Postscript
Many of these things can be implemented at a low level by pixelshaders, but whats the point of a high-level API that simply exposes a lower-level API?
Even though these things can't easily be accelerated by current consumer hardware, neither could gouraud-shaded polygons a few years back.
OpenGL does not seem to be moving forward in defining new and easy ways to define computer imagery, and is chasing the tail of DirectX, seemingly to avoid losing relevance as a gaming platform.
This, to me, is not the right approach - I don't want to see OpenGL discarded by games programmers, but I also want to see OpenGL become a more powerful API across-the-board that makes my life as graphics programmer easier, not harder.
Re:Games are good but... (Score:2, Informative)
Voxel primitives are there: 3D textures.
Radiosity and raytracing are difficult to put in hardware because they would require you to have a full description of the scene in memory. This flies agains a fundamental assumption of OpenGL that geometry may be streamed to the video card -- keep the state small. A scene description language that performs radiosity calculations should be a layer on top of OpenGL, not subsumed into it. OpenGL's design intent has always been "Provide a wafer-thin layer of sanity over the graphics hardware so that people can make things go really fast." It has never been "Make programming graphics easy." Making graphics programming easy is the job of other layers such as Crystal Space [sourceforge.net] (games) or VTK [vtk.org] (visualization).
Lazy state updates! (Score:3, Informative)
State changes are SLOW, and so anyone hoping to render mildly complex scenes had better find a better alternative to resetting the state for every object in the scene. Well, there is... lazily update the states (only change the states that need changing, instead of manually setting every one). You could even go one step further and sort how you render your objects based upon state, so as to cause the least number of changes possible.
Today, OpenGL drivers DO NOT KEEP TRACK OF THE STATE. They just merrily pass the state-changing function calls along. Thus, the programmer is forced to go through the tedium of creating some abstraction of OpenGL states, and tending to it themselves. This is frustrating boring work, there is no reason this shouldn't happen transparently!
VTK is (or at least was, last I heard) guilty of not managing states lazily. A professor around here was working on a project to render from VTK to a large tiled display, which he did by more or less replacing the opengl driver with his own custom tile-display creation. It just happened to lazily update states. The end result was the uber-demo-model displaying smoothly on the tiled display, while chunking along at 10-15 FPS on the actual computer monitor!
OpenGL implementations need to keep track of their rendering states, not just send the requests off to the card!
- spiff
Why Direct3D Is more predominent (Score:2, Interesting)
Here's what I hope they get right (Score:2, Insightful)
1. Vertex/Index Buffers
The only way to store geometry data on the video card is by using extensions. To make matters worse, you passs nvidia's extension a couple floating point numbers and it magically gives you a block of memory if it feels like it, or not. Then this is the only block you get. Its up to you to write a memory manager on top of it
2. Documentation / Extension system
First, there hasn't been any HTML or even plaintext specs of the newer APIS. The PDFs look like ASS because of the pdf fonts. Second the extensions are made so that they are incremental updates to the manual "insert these lines into section 4.3.10" This helps no one use the extension. Why can't they just be explained in full. Plus, the least important fields such as the "issues" should go towards the bottom of the spec.
3. Arcane extensions with arcane (or no) docs
i'm talking about stuff like the nvidia register combiners, fence, vertex array range. And a powerpoint outline doesn't do the job explaining these.
Hardware Independence (Score:2, Informative)
I hope OpenGL doesn't die! (Score:4, Insightful)
Joking aside, I hope, and know that OpenGL will never die. Several reasons:
To summarize:
I love OpenGL and everything about it. I know it will never die. Its an incredible API, and although its slow to update, I'm sure OpenGL2.0 will kick ass.
-Vic
Re:I hope OpenGL doesn't die! (Score:5, Insightful)
Right... Either you've never used DX8/9, you've never used OpenGL without glut, or both. Both API's have their good points and bad points in ease-of-use. But as of today (and especially with DX9), I would give the nod to D3D here. There are too many things that are vendor specific in OpenGL that are required for fast operation. This turns into a big pain in the ass. Also, anyone who's written wrapper code to dynamically load DX or OpenGL libraries at run time knows that the C++ interface of DX is a godsend.
Cross platform. Direct3D doesn't run on other platforms (yeah, there's probably a project or two on sourceforge to prove me otherwise), but in general, you don't have to install any fancy things to get OpenGL working on multiple computers. In fact, if you use the GLUT (although deprecated, it has its uses) library, then theorhetically, you should only have to recompile the application to have it run on a specific platform.
Cross platform is right, easy to port, not-so-right. Even when using glut, extensions that exist on the PC's are usually different than apple's extionsions that do the same damn thing. Apple's policy towards OpenGL is similar to the way MS treats DX. The only time the API is updated is when Apple approves of new GL_APPLE extensions. There is no aglGetProcAddress, so vendors are not at liberty to add new extensions when they please. I'll admit that this could be viewed as a good thing, but it does make developing at the bleeding edge more than a little difficult.
John Carmack. Face it, the mans incredible. He's literally changed the face of graphics, but I'm sure everyone already knew that ;).
Unfortunately, only John Carmack can tell the IHV's what to do and what extensions to support in OpenGL. Yes, he's helped OpenGL, but what does Carmack have to do with you choosing to use OpenGL vs. DX?
The general API is nicer looking. To me, and I'm sure a lot of other people, code aesthetics is very important. OpenGL uses simple, yet intuitive function names. I want my object to be 100% red, and 50% blue, and 0% green, simple, I must use the glColor3f(1.0f, 0.5f, 0.0f); function (gl - the library, Color - main identifier, 3f - takes 3 floats as arguments). I'm not sure of the function in Direct3D, but I'm sure its not as nice looking.
Write back when you've tried using programmable shaders under OpenGL (especially fragment/pixel shaders). Personally (and I know I don't speak for everyone), I perfer the DX api to GL's. I also prefer DX's standard vertex lighting model to GL's (the spot light formulae (sp?) are different). The DX fixed function pixel pipeline is more flexible than GL's standard (GL_ARB_texture_env_combine) pixel pipeline.
In my summary: OpenGL and DX are very equivalent in functionality. OpenGL tends to have MORE function calls into the library, but DX has more EXPENSIVE function calls into the library - so this is a wash. I do hope OpenGL 2.0 will kick ass, but I'm also hoping it's a step towards the day when DX and OpenGL have easily translatable shading languages and features for everything. It's not there yet.
open source is indeed behind Windows (Score:3, Insightful)
Let people worry a few more years about DirectX and OpenGL 2 features and see how things shake out; then, those things may be mature enough to be widely used and built on. Until then, a good OpenGL 1.x implementation is all I want.
Misconceptions about OpenGL (Score:5, Informative)
First thing: there's is a common misconception that DirectX is "light years" ahead of OpenGL. That couldn't be more false. There are quite a few things that you can do in OpenGL that you wouldn't be able to in DirectX. Here's a good example: GeForce register combiners.
On the other hand there is nothing DirectX (or more correctly Direct3D) can do that OpenGL can't. All of the functionality is present through extensions.
Main problem with OpenGL is not functionality - it's the extensions. Different graphics cards support different extensions that provide the same functionality but to get your code to run on both cards correctly you have to support both extensions.
The whole extensions mechanism is a mess really - it was a good idea while the number of extensions was small but these days there are way too many of them.
Another misconception (and I just can't see where exactly is this coming from) is that DirectX is faster than OpenGL. On nVidia cards at least DirectX is most definitley not faster than OpenGL. Run any game that supports both APIs and OpenGL is almost always faster. This is not noticable on really powerful systems but on slower ones OpenGL runs slightly faster. For that matter just look at all the abstraction present in DirectX - abstraction does not come for free, there is a performance cost - it's small but it's there. OpenGL on the other hand is nice and clean.
Not to mention that DirectX uses a lot more memory than OpenGL.
I also noticed someone saying that DirectX drivers are easier to implement. That is most certainly not true. I find it puzzling that there are so many graphics cards with bad OpenGL drivers because OpenGL drivers are relatively simple compared to DirectX ones. I'm guessing the main reason is that DirectX is more popular and hence better supported.
And to the guy who mentioned hardware independence, sorry to disappoint you but OpenGL 2 will not be any more or less hardware independent than OpenGL 1.x.
OpenGL is a standard just like DirectX, not a driver. That means that graphics card companies will still have to write OpenGL 2 drivers - there won't be one driver for all OpenGL 2 cards. Before you post something incredibly stupid again use your brain for a minute and think about it.
Solid support for Linux would make a difference (Score:3, Interesting)
I certainl will just dream about the next part, but here goes...
I would like to see a standard OpenGL 2.0 implementation for Linux, with implementations for all new cards, that is not tied to X (whether or not it should be somehow connected to the kernel, well, is a decision for the implementors). I want it to be stable, fast, and state of the art.
This would:
1. Give me as a developer one API that I know will always be there, and I won't have to care about what card might be in the computer.
2. Give game developers the same as in 1
3. Make it feasable to port X to OpenGL 2.0 to improve the horrible performace
4. Write a new windowing system based on OpenGL 2.0 and put KDE/QT on top of it to make the Linux desktop experience more up to par with MacOS X for example (i.e. not make a copy of MacOS X, but start using more of your hardware for a smoother ride). (If you prefer gnome, the same goes for it
One of the reasons OpenGL kind of stood still... (Score:3, Interesting)
Farenheit was going to be the "high-end" graphics API, while DirectX would serve for "low-end". Well, you can attribute it to malice aforethought or simply reading the times, but MS withdrew leaving Farenheit dead in the water. Meanwhile OpenGL had pretty much stayed still.
Four years is a long time in 3D graphics. It's pretty sad that DirectX hasn't been able to open up MORE of a lead...
An overlooked feature of GL2 (Score:3, Interesting)
Working with a 3D graphics card is sort of like working with a second processor. Ideally, you would send the hardware a bunch of stuff to draw, and then you would do something else with the CPU (i.e. physics calculations) while you wait for the card to draw it. However, with GL 1.x, there isn't any really good way to do this (as far as I know). Once you queue up everything you want the card to draw for a particular frame of animation, you call your swap buffer function and your program just waits for everything to complete. The CPU just sits and does nothing. The only way to take advantage of the situation would be to use multiple threads, but then you run into thread synchronization issues, race conditions, and other crap you might not want to deal with.
With GL2, you can actually have the graphics card signal you when it's done. This signalling is done through low-level OS events, which are OS-dependent (unfortunately), but this means that you can wait on non-graphics-related events at the same time (networking, input, etc.) and handle them all as they happen. No more polling! This is good! Also, instead of queuing up an entire frame at once and then waiting for that, you can queue up bits and pieces and say "tell me when this piece has been drawn".
I guess this excites me more than most people because I am an extreme supporter of event-driven programming. Threads are inefficient and overrated, IMO; a program should never use more threads than its host has processors. Any operation which forces a thread to wait for something cannot be used in such programming models, which means I have a very hard time using GL 1.x effectively. 2.0 will fix that.
Re:Too little too late? (Score:3, Interesting)
So it'll disappear from the desktop, only to stay alive where it matters, on the workstations of people using serious applications, like CAD/CAM to name just an example. (And no, not all CAD/CAM happens on intel boxes, actually SGI has this market cornered, guess where OpenGL comes from?)
Yeah yeah, I know the parent is a troll, but I decided to bite. *shrug*
Re:Too little too late? (Score:2)
(And no, not all CAD/CAM happens on intel boxes, actually SGI has this market cornered, guess where OpenGL comes from?)
Actually, current SGI boxes have Intel(tm) inside. For better or worse, it's been that way for a LONG time now.
Re:Too little too late? (Score:2)
Did you know that they ditched NT as a recommended platform? Those SGI Visual workstation you talk about come with Linux preinstalled.
And the SGI MIPS machines are still widely used. I used to work for a R&D company that did a lot of CAD/CAM. I had to administer those Octanes and Indigo's that were used as workstations for stuff like Alias Wavefront.
I also doubt that people working on a SGI IRIX machine would give it up that easily :) In fact, that same company wanted to use NT for CAD/CAM. I heard the phrase "They'll get my machine when they pry it from my cold dead fingers" a lot.
Re:Too little too late? (Score:2)
Re:Too little too late? (Score:5, Funny)
Re:where the support is (Score:3, Interesting)
Carmack wants OpenGL for the same reason I do. Because it's an open platform.
Re:where the support is (Score:2, Informative)
You can also get support for OpenGL from the major companies that back it.
OpenGL is a real standard -- widely accepted, open and free (as in liberty), and cross-platform. It is used by serious people with serious needs. It supports more than just games, but it also performs very well in games as well.
OpenGL is catching up to DirectX in terms of gaming performance, but that's not all that matters. Want to do some 3D rendering? That's OpenGL.
DirectX is just a toy which is only useful for gaming on Wintel computers. Want to use an OS other than Windows, too bad. DirectX is a one-trick dog.
In short, DirectX is no standard at all. Its only useful for gaming. In short, all things considered, it is crap with the exception of gaming performance.
Re:where the support is (Score:2)
Of course, you're neglecting the fact that a lot of 3d rendering *is* through games. Currently, and for roughly for the last two years, the vast majority of game development has been done through DirectX.
I use both Direct3d and OpenGL daily, and I generally prefer OpenGL for most work. However, if I was starting to write a large game engine tommarow, I would pick Direct3d. It would continue to be my choice until OpenGL 2.0. I don't really feel like writing equivalent code for different video cards (again), as I would have to do with some OpenGL 1.x extentions. Direct3d was once a horrible API, but has really come onto it's own since DirectX 5.0, and especially 7.0. I really hope that OpenGL 2.0 succeedes as it would make game development much easier with it.
Re:where the support is (Score:2)
Re:where the support is (Score:2, Informative)
Who supports DirectX: Microsoft, Nvidia, Matrox, ATI, 95% of all game developers.
It may interest you to know that the following companies are official members of the OpenGL Architecture Review Board [opengl.org]:
Microsoft, Nvidia, Matrox, ATI
Re:OpenGL r0x0rs (Score:2)
Re:Won't MS foobar this? (Score:3, Informative)
You are wrong. OpenGL drivers are just that, hardware drivers. Updating OpenGL on Windows is simply a matter of replacing a DLL. Microsoft's support or lack thereof simply means that those DLLs will have to be written by 3d parties.