ARB meeting notes posted

Not only September but December

About the September meeting, I agree that a DX has big marketing… For me, I feel tempted when I received the DXSDK or when I assist to a D3D conference.
But it is true that OpenGL has some other problems like the lack of a common interface for what D3D calls PixelShaders 1.1, it is often late in having common extensions for basic things (we had to wait for years for the VBO extensions), and it seems to be following D3D: they have Vertex Shaders and we had to wait for months to have them, they have HLSL and we begin to have it now with the first ATI driver exposing it released this month (they have it from the end of 2002) and no news about it from NVIDIA.
Also, they should note that in the D3D mailing list, there are always answers from IHV people and MS and sometimes about things of future driver features, when they are planned to be available and things like this. Here you can ask about when will be GLSL in NVIDIA drivers or about the state of the highly-anticipated superbuffers extension and you will have no answer. This causes a big frustration in developers.
Of course, this is just my opinion and my feelings like an OpenGL developer many times tempted by D3D.

Like developers, why are you tempted by D3D?

Good render target mechanism + vertex buffers have been in there for years, none of this insane VA/CVA/VAR/VOB/VBO malarky, in d3d you always gave over resource location issues to the driver, which is where it has always belonged.
Apart from that, OpenGL is where the smart money is.

I have to agree with Zak.

Ah, it was about time

mmmm superbuffers.

And when are we NVIDIA users going to get GL HLSL support in the forcewares. It’s taking too long.

-SirKnight

Looks to me like nV are spending far more time on the DX side of things - with nV Perf Mon and now the HLSL FX Composer (BTW - Did you mean GLSL?)

Yeah I guess I do mean that. I forgot exactly what it’s being called now. But you are probably right that NV is spending a lot more time on DX to get that working faster than it does. Mostly because of Half-Life 2.

-SirKnight

Another note:

Have you tried to compile the examples from the OpenGL Programing Guide (Fourth Edition-> OpenGL 1.4) in Windows.
You can download the examples from ftp://ftp.sgi.com/opengl/opengl114.zip (By the way, I think they should be in opengl.org as the book is from the ARB. At least this is the conclusion looking the cover where it says OpenGL Architecture Review Board)

The examples just include gl/glut.h (which includes gl/gl.h). I have no see any gl.h that is up to opengl 1.4 so the first operation you should do (after finding a good copy of glut.h glut.lib and including them in the includes directory). If you have some experience, you know you have to find the latest copy of glext.h and include it (the book says that it is for additional extensions and that you could include it if you plan to use one of these additional extensions. Ironically, it also says that you can find it in opengl.org and I really don’t know where. Al this info is ‘hidden’ in the page 16 of the book).
Of course the book supposes not only that you have a 1.4 gl.h but a 1.4 lib/dll that it is well known that Windows if far from it.
So you have to see what OpenGL 1.4 functions are using and edit the example and add those weird and non-elegant lines of code:
PFNGLMULTITEXCOORD2FARBPROC glMultiTexCoord2fARB;
PFNGLACTIVETEXTUREARBPROC glActiveTextureARB;
(for example)
And of course, find the initialization code and add the lines to get those pointers:
glMultiTexCoord2fARB=(PFNGLMULTITEXCOORD2FARBPROC)wglGetProcAddress(“glMultiTexCoord2fARB”);
glActiveTextureARB=(PFNGLACTIVETEXTUREARBPROC)wglGetProcAddress(“glActiveTextureARB”);

And this is from the book that is suggested to start learning OpenGL. Can you imagine a programmer (experienced or not) that want to try to learn OpenGL with this book and can’t compile/try the examples included?
On the other side, you can download de D3D SDK, install it, read the entire documentation, run the compiled examples with the sample browser…

(The book does not include any CD with any SDK or similar).

I’m an OpenGL advocate and all those ‘constructive critic’ is trying to help ARB people to see what are our concerns.

In one side you have an API that is late exposing the common features of a HW generation. Governed mainly by the IHV that creates this HW. That sometimes implemented the approved features very late (GLSL extension was approved on June with some previous months of work) and sometimes they implemented it with bugs. With some features missing (render-targets for example). With no SDK (a compact set of documentation, examples, headers, libraries, etc.). With a very limited and old utility library. Whose lib version in Windows is limited to 1.1 and you have to access higher versions (up to 1.5 now) features via the extension mechanism. With very little support from IHV and usually not about their hw/driver features, and no support from the ARB about current or future features in their forums.
(I want to note that there have been features like ARB_fragment_programs that were a big win for the ARB. It is not only an ARB extension but it was approved/released before this feature was available in D3D).

On the other side we have an API governed by a company and just for the Windows OS. It exposes new features, even before than the HW that supports them is available (and although it doesn’t expose everything the other API don’t take advantage of it). It has not only a complete SDK (that is sent boxed to some developers and can be downloaded by everybody) but some interesting tools from the IHV that governed the other API, like Rendermonkey from ATI (although they have promised GLSL support for a future version), like the mentioned PerfMon or the mentioned HLSL FX Composer from NVIDIA. This SDK also includes a complete utility library (D3DX) optimized for some processors that allows to load meshes, textures, convert height maps to normal maps, complete math operations including quaternions, has an effect format, etc. The SDK also has some exporters, utility tools (D3DSpy, Mesh Viewer, DXTex, Texture Viewer, …) to help the developers. It also has an extensive documentation with examples ready to run. This API also has conferences from the company that governed the API (Meltdown), but also NVIDIA’s Gathering of Developers (it is true that they have some mentions of OpenGL in it) or ATI’s Mojo (just D3D). Lots of books about it. With a mailing list where the people who created the API and the IHV people answer questions about the API and even answer when a feature is planned to be available in their driver. With all IHV focusing in having all the features well implemented in their drivers.

With this scene, if you are a new, API-agnostic, developer who wants to learn a 3D API for Windows. What one will you take?

In my opinion, the ARB don’t have just to focus in current professional ISV but also in attract new/beginner developers. It should be done making it not only attractive (they can use all the features that their latest hw have) but also it should be easy to learn, try, etc. (and not only examples to draw triangles or quads but models, animated models, etc).

Maybe the ARB really does need to get some kind of extension-loading library that is official. Something that is simple to use (a few calls at most), and is frequently updated (whenever a new extension is approved). The initialization of the library will cause it to load all core features. From there, it is up to the users to get extensions.

I agree that OpenGL’s biggest problem is being attractive to new Windows users (or any platform that needs to get core features through GetProcAddress. I think that’s only Windows). Certainly, examples out of official OpenGL publications should be able to be compiled and run on a Windows box.

Can’t somebody keep opengl32.dll (or changing name like opengl2.dll) up-to-date? Let say a yearly based version, newer extension will be used with the old extension mechanism, waiting a new release.

It isn’t so difficult, it just need to be someone from the ARB, or even an opensource projet mandated by the ARB.

Customer will install it as DirectX, when they install new games.

A real SDK, with real doc will be usefull too, but it’s more work.

[This message has been edited by TheSillyJester (edited 01-15-2004).]

My personal opinion is that ARB needs to attract the big game developers to use OpenGL. Many new graphic developers choose their API based on their favorite games/engines. One of the main factors that kept OpenGL alive in the dev community was the presence of the Quake engines based games. Many new enthusiasts get to work with OpenGL based on that.

Talking with decision factors of some companies I was surprise to find out that they chose DirectX because there are many games already made with that API and this gave them confidence. Also there is this opinion (especially among non tech guys) that everything made by MS is good (and that’s good marketing from MS and we cannot blame them for that). They were non technical guys but still they took the final decision about the dev platform. While talking with the actual developers (the programmers) you will found out that they would rather prefer OpenGL because is (still!) a clearer API.

There is a certain danger for the OpenGL to become more complex in syntax than DirectX due to increase no of extensions. Here ARB should interfere and act more quickly to emerge the entire hardware specific extensions into a big standard. The thing about DirectX being simpler to use right now is not true yet (see all versions of shaders in directx). But I don’t want to get into this here.

The main point I want to make here is that attracting individual programmers (enthusiasts) to work with OpenGL is not that important than attracting the main actors in the industry. Even though you create a good pool of programmers they will be still forced to work with directx when hired.

Well, when you take a look at the December Meeting Notes, than you will recognise, that they plan to add an “ARB_extensions_query” extension.

That would be nice, if it would do all the intialization-stuff. However the description sounds, as if it is only an easier way to query IF an extension is available, nothing more.

I don´t really understand this. A driver is a DLL, right? When i use OpenGL, i access that DLL, right? This DLL gets updated everytime i install a new driver. So, why is it not possible, that all those function-pointers get stored inside the DLL, and also initialized. That way i would need nothing more than an “extern bla-function”, to tell the compiler, that the function-pointer is inside the DLL.

Wouldn´t that be possible? I don´t know much about DLLs, but it should work. So why do WE have to initialize all that ****, when the driver could already do that?

As we all know, John Carmack plans to quit his job as a graphics-programmer, after D3. If he really does it, is not sure. However, without any IMPORTANT 3D-engine using OpenGL nVidia and ATI will lose even more interest in it.
I love OpenGL. But i won´t use it for the sake of using it, but only as long as it is better (in my opinion) than D3D.

Jan.

Originally posted by Jan2000:
I don´t really understand this. A driver is a DLL, right? When i use OpenGL, i access that DLL, right? This DLL gets updated everytime i install a new driver. So, why is it not possible, that all those function-pointers get stored inside the DLL, and also initialized.

Wrong. You access OpenGL32.dll (which then access your driver’s gl dll). IIRC, Ms claimed that this DLL is part of the OS so no1 else is authorized to update it. That’s why we’re stucked with this old version.

Wait, which DLL gets updated by the driver? OpenGL32.DLL or the other DLL?

If a driver-update would update OpenGL32.dll, than that mechanism could be put into it.

[This message has been edited by Jan2000 (edited 01-15-2004).]

Originally posted by Jan2000:
[b]Wait, which DLL gets updated by the driver? OpenGL32.DLL or the other DLL?

If a driver-update would update OpenGL32.dll, than that mechanism could be put into it.[/b]

The OpenGL32.dll is part of the Os, not of the driver. No driver is allowed to alter it.

The driver opengl lib is called nvoglnt.dll for Nv for example.

Damn!

Originally posted by Jan2000:
As we all know, John Carmack plans to quit his job as a graphics-programmer, after D3. Jan.

GameSpy: Are you going to retire after DOOM 3?
John Carmack: No. I’ve got at least one more rendering engine to write
http://www.gamespy.com/quakecon2003/carmack/

>>>Like developers, why are you tempted by D3D?<<<

I’m tempted because it is another technology.
It’s good to learn as much things as possible.

But looking at D3D code makes my head turn.

As for the meeting notes, it sounds like affirmative action is taking place.

The thing to do is bring together all these technologies together : GL, AL, IL, (something for 3D models?), ML and perhaps ES

To this date, when people think of GL strengths, they list cross platform.
If there was a full package like DX, but cross platform, I think the BIG developing houses would seriously consider a switch.

It’s good that the ARB recognized this.