As a.net developer, you have to notice that Managed DirectX doesn't exist anymore, and XNA is too nowhere near as powerful as MDX was. There is SlimDX, which is a binding around DX10, which is quite cool, but has only become available recently.
The Tao Framework is more or less the best thing out there right now for.NET. It provides cross platform.NET bindings for openGL, SDL/glut/glfw, as well as OpenAL, devil and CG. It's basically a cross platform XNA equivalent.... but a lot better;)
Whilst i appreciate/. is full of MS bashing, I'd actually suggest you go try mono with the Tao framework, and it might prove to be a suprisingly pleasing environment to work in....
"Stefan Eriksson and a man known only as "Trevor" were driving a limited-edition Ferrari Enzo down the Pacific Coast Highway in Malibu, California at a relaxing 165 mph. As luck would have it, they hit a bump in the road and flew into a concrete utility pole, ripping the car in two."
It later turned out (during the trial of Erikson) that the car was driving at 199mph when it crashed (because they'd been filming the speedo when it crashed - and the video was submitted as evidence).
The Bank of Scotland actually claimed ownership of the car after it was totalled - apparently Eriksson had ceased payments on the loan he'd got from them.
Eriksson accepted a plea bargain for three years in jail and deportation. He pleaded guilty to two counts of embezzlement and one count of illegal gun possession. He avoided an auto theft charge. Eriksson was released from prison on January 21, 2008.
The biggest difference between the Gizmondo and the Pandora is that the latter is intended for home-brew only, and is certainly not aimed as a PSP killer. With that in mind, it's hard to see how the Pandora can fail, bring down a large electronics company, destroy a Ferrari Enzo, and lose millions of investors cash in quite the same way as the Gizmondo managed......
IIRC, though can't find a reference to it, and can't remember which McDonald was suing. A few years ago in scotland a guy called McDonald, had been operating a shop in a town under the name of 'McDonalds'. The McDonalds chain were trying to open a new branch in the same town, but then realised that the town already had a McDonalds. Some lawsuit or other ensued, in which both parties claimed they had the right to the name. Unfortunately, i have no idea how it ended....
The difference in driving a turbo diesel vs petrol is the hill climb effect. In a petrol car, you start to feel the engine lose power as you climb a hill, then will be forced to drop down a gear. With diesel, just put your foot down, and you will accelerate - no matter what gear you are in.
Granted, I don't know what the VW turbo4s get for torque, but the fact remains, whatever that number is, a gas powered engine will get more.
The most notable characteristic of the R10 is its engine: a diesel engine, with two turbochargers - the TDI turbodiesel engine, running on Shell V-Power Diesel. It is a 5.5 L (335.6 cu in) all-aluminium twin-turbo 90 V12 engine, with common rail direct fuel injection of more than 1600 bar (23,206 psi). Its output should be 485 kW (659 PS/650 bhp) (regulated) and 1,100 Nm (811 ftlbf) of torque, and its usable power band is between 3000 and 5000 rpm. Its benefits are a broad range of usable power, high torque and economy.
I live in a grade II listed building (for the benfit of non UK people, that means a building of historical importance that has heavy restrictions on what modifications can be done to it), and as such am not allowed to install a roof top antennae - and can't install one in the attic, because it doesn't have one. With a crappy rabbit ear aerial (without a booster), i get a perfect digital TV reception, whereas the analogue signal is appalling (i.e 3 out of 5 channels, and even those are grainy)....
That must be why most of the 3D CGI in films sticks out so much.
Wrong department. You want to be blaming the compositors - not the rendering technique.
For any CG element to be comped into a live action plate you've got a few things to do:
1. When filming, accurately measure the lighting conditions. Typically this is done with white or chrome spheres, then later someone has the fun job of stiching together 6 or more photographs into a single environment map to attempt to simulate the lighting conditions.
2. After filming, someone has the fun task of match-moving the camera to attempt to create an exact copy of the motion in the 3D app. This is typically done by hand, though there are a few app's out there that can help.
3. The 3D texture artists and the shader writers then have to work together closely to be able to create a decent looking skin (or whatever the CG element is) material that's going to look realistic on it's own.
4. Hit render at this point you get a CG element. However that will never match the original film plate. Lets say you are putting some object under a tree, it won't have any of the shadows of the leaves. So the next thing that happens is that some poor goon has to go off and create a shadow model to build into the render process to be able make the object fit the scene better.
5. Eventually the CG plates are sent to the render wranglers for final production renders.
6. Then the compositor gets hold of them, will adjust the colours/brightness and modif the lighting model as much as possible on the 2D plates until the fit is as good as possible.
7. Finally that will be sent to be signed off by the director. If he signs it off, fine. If not, the whole process repeates itself until done.
If any of those elements are rushed, or for some reason happens to be a pita, then it's very easy for the CG to stand out from the background. Unfortunately in the film FX industry, those shots are typically needed about 3 weeks ago; there often isn't the budget available to perfect the shots 100%; and more often than not you'll get a producer who says "We're paying a lot of money for these shots, so we want you to brighten up the 3D elements so that the audience notices them!" (which more often than not, is the reason for sucky visual FX).
So basically, Ray tracing won't help you at all for any of that. Infact typically it's mathematical accuracy is actually a hinderance to making believable shots - you ideally want a pretty fudgable renderer - and normally that's Pixar's prman (which is not ray traced).
I used to hear exactly the same things being said by the ray-tracing evangelists in the FilmFX industry 15 years ago. Rasterization is still the primary techinique used for any film you care to mention, and I'm almost 100% certain it will still be the primary technique 30 years from now.
The only way to really tell is to take the exact same scene and lighting model, run both algorithms, then compare the results side by side, and in those comparisions, ray tracing wins hands down....
When rendered at 60fps in a fast paced car game, are you going to ever notice those minute details? Would you even care?
For the record, I think the quality of the images are pretty poor. Just look underneath the car at the back wheels (pic bottom left). The shadow colour is uniform, there's no texture, no detail, no ambient occlusion, the shadow edges are sharp, etc. For another example, take a look inbetween the 2 signs - now look down just a touch. Pretty horrible imo. Now move down just a little bit more till you get to the traffic cones. That red is most definately wrong. It's the same colour as the rear car lights. Due the distance it is from the camera, there should be some saturation fade on that colour (Notice that the traffic lights are all green, and that green is identical on all instances - regardless of distance).. Now look at the building directly behind the 'No Trucks' sign. See how there's a graduation in colour saturation from top to bottom? WTF is that about? It looks like a nasty fog hack rather than a high quality ray traced renderer.
The quality for everything in those images (apart from the reflections) is truly awful. It looks no better than than something you could do with openGL's fixed function hardware. That basically is the problem with ray tracing - It's not a technique you should be using everywhere, but use in places it's needed.
From what I know (which isn't much) even high end shops like Pixar only recently started using ray tracing, before that it was all rasterization using procedural textures and fairly complicated lighting models.
It still is all scan line rasterisation (it's a REYES renderer). The renderman spec recently added a trace command that you can use within the prman shaders, but it's only ever used for those specific edge cases where rasterisation isn't going to be up to the job (i.e. reflection and refraction).
Exactly. That's what OpenGL 3.0 was supposed to be - an improvement. We've been preparing for it for the last couple of years, only to be let down at the last moment. I'm not angry about that, just sad. I've spent the last 10 or so years working with OpenGL, and for some time it's been in desperate need for a clean break in order to remove the dependency on legacy cruft. Working in OpenGL often feels like you've been presented with 101 ways to skin a cat. Rendering a triangle in OpenGL is a good example. Display Lists, VBO's, VBA's, vertex arrays, immediate mode, NV fence, VAR, CVA, MultiDraw Arrays, interleaved arrays, and the list goes on. In D3D you have 2 methods - DrawPrimitive() or DrawIndexedPrimitive() and that's it. Any sane person would quickly realise that it's going to be a hell of a lot easier writing a driver for that than the GL methods.
They could be targeting all platforms with little extra effort. It's only M$ that doesn't want that to happen.
You didn't read my response correctly. If a developer is targetting windows only, you have 2 choices, D3D or GL. The difference in driver quality between D3D and GL is pretty big - due primarily to the current complexity of the openGL spec. A D3D driver in comparison has none of that legacy cruft and the result is relatively stable drivers for more or less every graphics card (Intels graphics cards are a good example - appalling openGL support!).
Hello? I feel like I'm talking to a marketing zealot here.
No, you're talking to an openGL programmer who writes animation software for a living (which incidentally is cross platform). Have you not been following anything that's been going on here? There is no astro-turfing going on for god's sake - In this instance Microsoft has been able to sit back and watch with amusement as the khronos group have erected their own gallows and hung themselves.
What part of "Look at all the posts that repetitively try to imply OpenGL isn't complemented by many other libraries." do you not understand?
I understand you perfectly - from experience they tend to be a bit of a mixed bag. More often than not, those libraries use display lists, immediate mode etc etc - all the things you don't want to be using in a high performance graphics app.
There are any number of free math and matrix libraries available.
Which are SSE optimised, fully featured, unit tested and include full documentation?
Your comment about the device driver bugs is makes sense though my understanding is that's a mainly a problem with the driver developers, not OpenGL.
It's not the driver devs, it's the GL spec that is the problem, plain and simple. ATI and Nvidia originally proposed GL3.0 as a way to simplify the driver writing process and better expose the power of the hardware to OpenGL. Take for example glBindTexture. Are you compiling a display list? Is aprogram bound? Does the texture object exist? (The spec makes no requirement for you to use glGenTextures() to generate the ID's - so the driver has to deal with those rare cases - even though few devs actually do that). The process of binding a texture has to interoperate with a multitude of legacy extensions, the vast majority of which are not used by developers these days. The net result is that the drivers are complicated, and anywhere upto 10% slower than they need to be (NVidia's figures, not mine). Take a look through some of the GL extensions and have a look at the dependencies section. That might start to give you an inkling as to why the drivers are buggy - It's a damned hard spec to code a driver against.
Lets take another example, geometry shaders. DX10 has had geometry shaders that run on ATI, Nvidia and Intel cards since it's release. OpenGL 3.0 was supposed to add them as a core part of the spec. It didn't. So now
However when we talk about render farms, we tend to be talking about large rooms filled with rack mount processors churning through shaders written for renderman or mental ray - not gelatto/CUDA/D3D/OpenGL. Whilst those are available, the simple fact is that there are generally not used in production houses who have had 20 or so years of experience using the toolchain they have in place.
OpenGL is perfectly adequate for the vast majority of graphics applications out there, including games, (e.g. Spore).
adequate != ideal
Unfortunately, OpenGL in it's current state is far from ideal. It's the ease of use of D3D when compared to OpenGL that makes developers targetting the Windows platform use D3D. Not to mention the maths library. The debugging tools (Pix). The samples. The documentation. Etc Etc.
DX9/10 is not critical for *keeping* developers on windows. The sheer number of windows users does that well enough already.
Developing with OpenGL is do-able (It's core to the App's i work on), but when you get support tickets with things like:
* Texturing has errors on a Voodoo 5.
* Crashes on ATI radeon.
* Widgets not visible on Intel X3100.
* Overlay's not visible on 3D labs Wildcat
Depends if you think that DX being closed source is a problem. I'd tend to err on the side that it isn't.
I have been part of the Khronos group previously (though not on openGL), but in general it tends to involve very long e-mail discussions about how X is broken. Half the people will agree. The other half will admit it's broken, but will be reluctant to change it because it'll require additional work for their companies (i.e. it'll cost them money to make that change). So whilst everyone may agree that a change is needed, very few people will vote to change it.
The result of months of e-mail discussions is basically not a lot. Unfortunately that's what happens with design by commitee. So whilst moving GL from the ARB to the Khonos group was well intentioned, I suspect that not very much has changed (as I think has been demonstrated with the GL3 spec).
The simple reason D3D keeps moving forward is that a dictator driven API can, and does, break the API in order to make progress. The sucky thing is that it's Windows only. If it was available on linux/mac/windows XP, then I'd gladly switch to D3D10....
I can't talk about autocad, but at our company we were aware of the shift in GL3 spec some time ago. As a result we invested fairly heavily in pre-empting those changes to make the rendering side of the codebase conform to the changes proposed last year (i.e. everything in buffers + shaders, removal of the selection buffer dependency etc). Since we had no GL3 to start with, we pulled all code under a wrapper, slapped it into a DLL, and used a DX10 dll as a starting point to see what the work on GL3 would entail.
So now have a working DX10 dll, a GL2.0 dll (all done with shaders + VBO's), and space for the new amazing shader driven GL3 API to slot into. Bum.
Todays news does not exactly make me think "Woo-Hoo we have backwards compatibility with GL1 - thank god we don't have to re-write any code".
The simple fact of the matter is that for the last year we have been told that this change is going to happen. As a result we have acted upon that. Our time has already been wasted. It would be nice if they had actually delivered what they told us to expect.
Slashdot Mirror
C# is an iso standard language, which puts it in the same league as C/C++.....
As a .net developer, you have to notice that Managed DirectX doesn't exist anymore, and XNA is too nowhere near as powerful as MDX was. There is SlimDX, which is a binding around DX10, which is quite cool, but has only become available recently.
.NET. It provides cross platform .NET bindings for openGL, SDL/glut/glfw, as well as OpenAL, devil and CG. It's basically a cross platform XNA equivalent.... but a lot better ;)
/. is full of MS bashing, I'd actually suggest you go try mono with the Tao framework, and it might prove to be a suprisingly pleasing environment to work in....
The Tao Framework is more or less the best thing out there right now for
Whilst i appreciate
There's a nice summary here
http://www.gamerevolution.com/features/gizmondo_bizarro
"Stefan Eriksson and a man known only as "Trevor" were driving a limited-edition Ferrari Enzo down the Pacific Coast Highway in Malibu, California at a relaxing 165 mph. As luck would have it, they hit a bump in the road and flew into a concrete utility pole, ripping the car in two."
It later turned out (during the trial of Erikson) that the car was driving at 199mph when it crashed (because they'd been filming the speedo when it crashed - and the video was submitted as evidence).
The Bank of Scotland actually claimed ownership of the car after it was totalled - apparently Eriksson had ceased payments on the loan he'd got from them.
From wikipedia: http://en.wikipedia.org/wiki/Stefan_Eriksson
Eriksson accepted a plea bargain for three years in jail and deportation. He pleaded guilty to two counts of embezzlement and one count of illegal gun possession. He avoided an auto theft charge. Eriksson was released from prison on January 21, 2008.
Don't forget to bring a towel....
*cough* Need for Speed - Pro Street *cough*
There were far more reasons as to why the Gizmondo failed......
http://www.gamerevolution.com/images/feature/gizmondo/flow_chart.gif
The biggest difference between the Gizmondo and the Pandora is that the latter is intended for home-brew only, and is certainly not aimed as a PSP killer. With that in mind, it's hard to see how the Pandora can fail, bring down a large electronics company, destroy a Ferrari Enzo, and lose millions of investors cash in quite the same way as the Gizmondo managed......
yeah, i always come to work to relax....
then grab nLite and create an updated install disk w/ service pack 3 on it...
apart from friday last week, when it was talk like a pirate day.
I suspect a LOT more computing power is thrown at more mundane things like predicting where the financial markets are going
;)
Even my tea leaves say down...
References:
1. ^ "A couple years ago a wiki page was created about a friend of mine who ran a website". Rutefoot, 2008
IIRC, though can't find a reference to it, and can't remember which McDonald was suing. A few years ago in scotland a guy called McDonald, had been operating a shop in a town under the name of 'McDonalds'. The McDonalds chain were trying to open a new branch in the same town, but then realised that the town already had a McDonalds. Some lawsuit or other ensued, in which both parties claimed they had the right to the name. Unfortunately, i have no idea how it ended....
The difference in driving a turbo diesel vs petrol is the hill climb effect. In a petrol car, you start to feel the engine lose power as you climb a hill, then will be forced to drop down a gear. With diesel, just put your foot down, and you will accelerate - no matter what gear you are in.
Granted, I don't know what the VW turbo4s get for torque, but the fact remains, whatever that number is, a gas powered engine will get more.
Much like the Audi R10?
The most notable characteristic of the R10 is its engine: a diesel engine, with two turbochargers - the TDI turbodiesel engine, running on Shell V-Power Diesel. It is a 5.5 L (335.6 cu in) all-aluminium twin-turbo 90 V12 engine, with common rail direct fuel injection of more than 1600 bar (23,206 psi). Its output should be 485 kW (659 PS/650 bhp) (regulated) and 1,100 Nm (811 ftlbf) of torque, and its usable power band is between 3000 and 5000 rpm. Its benefits are a broad range of usable power, high torque and economy.
v.s. The petrol powered Audi R8
553 lb-ft. @ 5500 rpm ('01-'02)
516+ lb-ft. ('04)
516 lb-ft. ('05)
correction: care bears.
In space, no one can hear you litigate....
I live in a grade II listed building (for the benfit of non UK people, that means a building of historical importance that has heavy restrictions on what modifications can be done to it), and as such am not allowed to install a roof top antennae - and can't install one in the attic, because it doesn't have one. With a crappy rabbit ear aerial (without a booster), i get a perfect digital TV reception, whereas the analogue signal is appalling (i.e 3 out of 5 channels, and even those are grainy)....
That must be why most of the 3D CGI in films sticks out so much.
Wrong department. You want to be blaming the compositors - not the rendering technique.
For any CG element to be comped into a live action plate you've got a few things to do:
1. When filming, accurately measure the lighting conditions. Typically this is done with white or chrome spheres, then later someone has the fun job of stiching together 6 or more photographs into a single environment map to attempt to simulate the lighting conditions.
2. After filming, someone has the fun task of match-moving the camera to attempt to create an exact copy of the motion in the 3D app. This is typically done by hand, though there are a few app's out there that can help.
3. The 3D texture artists and the shader writers then have to work together closely to be able to create a decent looking skin (or whatever the CG element is) material that's going to look realistic on it's own.
4. Hit render at this point you get a CG element. However that will never match the original film plate. Lets say you are putting some object under a tree, it won't have any of the shadows of the leaves. So the next thing that happens is that some poor goon has to go off and create a shadow model to build into the render process to be able make the object fit the scene better.
5. Eventually the CG plates are sent to the render wranglers for final production renders.
6. Then the compositor gets hold of them, will adjust the colours/brightness and modif the lighting model as much as possible on the 2D plates until the fit is as good as possible.
7. Finally that will be sent to be signed off by the director. If he signs it off, fine. If not, the whole process repeates itself until done.
If any of those elements are rushed, or for some reason happens to be a pita, then it's very easy for the CG to stand out from the background. Unfortunately in the film FX industry, those shots are typically needed about 3 weeks ago; there often isn't the budget available to perfect the shots 100%; and more often than not you'll get a producer who says "We're paying a lot of money for these shots, so we want you to brighten up the 3D elements so that the audience notices them!" (which more often than not, is the reason for sucky visual FX).
So basically, Ray tracing won't help you at all for any of that. Infact typically it's mathematical accuracy is actually a hinderance to making believable shots - you ideally want a pretty fudgable renderer - and normally that's Pixar's prman (which is not ray traced).
I say rasterization sticks around 3-5 years.
I used to hear exactly the same things being said by the ray-tracing evangelists in the FilmFX industry 15 years ago. Rasterization is still the primary techinique used for any film you care to mention, and I'm almost 100% certain it will still be the primary technique 30 years from now.
The only way to really tell is to take the exact same scene and lighting model, run both algorithms, then compare the results side by side, and in those comparisions, ray tracing wins hands down....
When rendered at 60fps in a fast paced car game, are you going to ever notice those minute details? Would you even care?
For the record, I think the quality of the images are pretty poor. Just look underneath the car at the back wheels (pic bottom left). The shadow colour is uniform, there's no texture, no detail, no ambient occlusion, the shadow edges are sharp, etc. For another example, take a look inbetween the 2 signs - now look down just a touch. Pretty horrible imo. Now move down just a little bit more till you get to the traffic cones. That red is most definately wrong. It's the same colour as the rear car lights. Due the distance it is from the camera, there should be some saturation fade on that colour (Notice that the traffic lights are all green, and that green is identical on all instances - regardless of distance).. Now look at the building directly behind the 'No Trucks' sign. See how there's a graduation in colour saturation from top to bottom? WTF is that about? It looks like a nasty fog hack rather than a high quality ray traced renderer.
The quality for everything in those images (apart from the reflections) is truly awful. It looks no better than than something you could do with openGL's fixed function hardware. That basically is the problem with ray tracing - It's not a technique you should be using everywhere, but use in places it's needed.
From what I know (which isn't much) even high end shops like Pixar only recently started using ray tracing, before that it was all rasterization using procedural textures and fairly complicated lighting models.
It still is all scan line rasterisation (it's a REYES renderer). The renderman spec recently added a trace command that you can use within the prman shaders, but it's only ever used for those specific edge cases where rasterisation isn't going to be up to the job (i.e. reflection and refraction).
There's always room for improvement.
Exactly. That's what OpenGL 3.0 was supposed to be - an improvement. We've been preparing for it for the last couple of years, only to be let down at the last moment. I'm not angry about that, just sad. I've spent the last 10 or so years working with OpenGL, and for some time it's been in desperate need for a clean break in order to remove the dependency on legacy cruft. Working in OpenGL often feels like you've been presented with 101 ways to skin a cat. Rendering a triangle in OpenGL is a good example. Display Lists, VBO's, VBA's, vertex arrays, immediate mode, NV fence, VAR, CVA, MultiDraw Arrays, interleaved arrays, and the list goes on. In D3D you have 2 methods - DrawPrimitive() or DrawIndexedPrimitive() and that's it. Any sane person would quickly realise that it's going to be a hell of a lot easier writing a driver for that than the GL methods.
They could be targeting all platforms with little extra effort. It's only M$ that doesn't want that to happen.
You didn't read my response correctly. If a developer is targetting windows only, you have 2 choices, D3D or GL. The difference in driver quality between D3D and GL is pretty big - due primarily to the current complexity of the openGL spec. A D3D driver in comparison has none of that legacy cruft and the result is relatively stable drivers for more or less every graphics card (Intels graphics cards are a good example - appalling openGL support!).
Hello? I feel like I'm talking to a marketing zealot here.
No, you're talking to an openGL programmer who writes animation software for a living (which incidentally is cross platform). Have you not been following anything that's been going on here? There is no astro-turfing going on for god's sake - In this instance Microsoft has been able to sit back and watch with amusement as the khronos group have erected their own gallows and hung themselves.
What part of "Look at all the posts that repetitively try to imply OpenGL isn't complemented by many other libraries." do you not understand?
I understand you perfectly - from experience they tend to be a bit of a mixed bag. More often than not, those libraries use display lists, immediate mode etc etc - all the things you don't want to be using in a high performance graphics app.
There are any number of free math and matrix libraries available.
Which are SSE optimised, fully featured, unit tested and include full documentation?
Your comment about the device driver bugs is makes sense though my understanding is that's a mainly a problem with the driver developers, not OpenGL.
It's not the driver devs, it's the GL spec that is the problem, plain and simple. ATI and Nvidia originally proposed GL3.0 as a way to simplify the driver writing process and better expose the power of the hardware to OpenGL. Take for example glBindTexture. Are you compiling a display list? Is aprogram bound? Does the texture object exist? (The spec makes no requirement for you to use glGenTextures() to generate the ID's - so the driver has to deal with those rare cases - even though few devs actually do that). The process of binding a texture has to interoperate with a multitude of legacy extensions, the vast majority of which are not used by developers these days. The net result is that the drivers are complicated, and anywhere upto 10% slower than they need to be (NVidia's figures, not mine). Take a look through some of the GL extensions and have a look at the dependencies section. That might start to give you an inkling as to why the drivers are buggy - It's a damned hard spec to code a driver against.
Lets take another example, geometry shaders. DX10 has had geometry shaders that run on ATI, Nvidia and Intel cards since it's release. OpenGL 3.0 was supposed to add them as a core part of the spec. It didn't. So now
It's 24, you forgot about the 32 and 64 bit versions.
However when we talk about render farms, we tend to be talking about large rooms filled with rack mount processors churning through shaders written for renderman or mental ray - not gelatto/CUDA/D3D/OpenGL. Whilst those are available, the simple fact is that there are generally not used in production houses who have had 20 or so years of experience using the toolchain they have in place.
OpenGL is perfectly adequate for the vast majority of graphics applications out there, including games, (e.g. Spore).
adequate != ideal
Unfortunately, OpenGL in it's current state is far from ideal. It's the ease of use of D3D when compared to OpenGL that makes developers targetting the Windows platform use D3D. Not to mention the maths library. The debugging tools (Pix). The samples. The documentation. Etc Etc.
DX9/10 is not critical for *keeping* developers on windows. The sheer number of windows users does that well enough already.
Developing with OpenGL is do-able (It's core to the App's i work on), but when you get support tickets with things like:
* Texturing has errors on a Voodoo 5.
* Crashes on ATI radeon.
* Widgets not visible on Intel X3100.
* Overlay's not visible on 3D labs Wildcat
It does start to get a little bit depressing....
Depends if you think that DX being closed source is a problem. I'd tend to err on the side that it isn't.
I have been part of the Khronos group previously (though not on openGL), but in general it tends to involve very long e-mail discussions about how X is broken. Half the people will agree. The other half will admit it's broken, but will be reluctant to change it because it'll require additional work for their companies (i.e. it'll cost them money to make that change). So whilst everyone may agree that a change is needed, very few people will vote to change it.
The result of months of e-mail discussions is basically not a lot. Unfortunately that's what happens with design by commitee. So whilst moving GL from the ARB to the Khonos group was well intentioned, I suspect that not very much has changed (as I think has been demonstrated with the GL3 spec).
The simple reason D3D keeps moving forward is that a dictator driven API can, and does, break the API in order to make progress. The sucky thing is that it's Windows only. If it was available on linux/mac/windows XP, then I'd gladly switch to D3D10....
I can't talk about autocad, but at our company we were aware of the shift in GL3 spec some time ago. As a result we invested fairly heavily in pre-empting those changes to make the rendering side of the codebase conform to the changes proposed last year (i.e. everything in buffers + shaders, removal of the selection buffer dependency etc). Since we had no GL3 to start with, we pulled all code under a wrapper, slapped it into a DLL, and used a DX10 dll as a starting point to see what the work on GL3 would entail.
So now have a working DX10 dll, a GL2.0 dll (all done with shaders + VBO's), and space for the new amazing shader driven GL3 API to slot into. Bum.
Todays news does not exactly make me think "Woo-Hoo we have backwards compatibility with GL1 - thank god we don't have to re-write any code".
The simple fact of the matter is that for the last year we have been told that this change is going to happen. As a result we have acted upon that. Our time has already been wasted. It would be nice if they had actually delivered what they told us to expect.