PDA

View Full Version : ARB meeting notes posted



Zak McKrakem
01-14-2004, 08:39 AM
Not only September but December http://www.opengl.org/discussion_boards/ubb/smile.gif

Zak McKrakem
01-14-2004, 09:13 AM
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?

KuriousOrange
01-14-2004, 09:26 AM
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.

Jan
01-14-2004, 09:43 AM
I have to agree with Zak.

SirKnight
01-14-2004, 11:26 AM
mmmm superbuffers. http://www.opengl.org/discussion_boards/ubb/biggrin.gif

And when are we NVIDIA users going to get GL HLSL support in the forcewares. It's taking too long. http://www.opengl.org/discussion_boards/ubb/frown.gif


-SirKnight

zeckensack
01-14-2004, 11:26 AM
Ah, it was about time http://www.opengl.org/discussion_boards/ubb/smile.gif

rgpc
01-14-2004, 03:01 PM
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?)

SirKnight
01-14-2004, 04:38 PM
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

Zak McKrakem
01-15-2004, 01:40 AM
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)wglG etProcAddress("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).

Zak McKrakem
01-15-2004, 03:00 AM
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).

Korval
01-15-2004, 03:38 AM
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.

TheSillyJester
01-15-2004, 04:41 AM
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).]

Licu
01-15-2004, 05:14 AM
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.

Jan
01-15-2004, 05:59 AM
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.

tfpsly
01-15-2004, 06:10 AM
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.

Jan
01-15-2004, 06:30 AM
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).]

tfpsly
01-15-2004, 06:46 AM
Originally posted by Jan2000:
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.

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.

Jan
01-15-2004, 09:21 AM
Damn!

Adrian
01-15-2004, 09:38 AM
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/

V-man
01-15-2004, 12:06 PM
>>>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.

pkaler
01-15-2004, 12:25 PM
Originally posted by V-man:

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


Creative has dropped the ball on OpenAL. Maybe nVidia will push it forward with their onboard audio solutions.
DevIL is quite good.
3D models are a mess since CAD and modelling companies want to keep their formats proprietary.
Can't speak about ML or ES, don't have any experience.

Jan
01-15-2004, 12:28 PM
Originally posted by V-man:
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.

I have the sad feeling, that you are interpreting too much into their statements.

@Adrian: Thanks for proving me wrong http://www.opengl.org/discussion_boards/ubb/smile.gif

Jan.

rgpc
01-15-2004, 03:37 PM
Originally posted by V-man:
The thing to do is bring together all these technologies together : GL, AL, IL, (something for 3D models?), ML and perhaps ES


But why? They're nothing more than a set of API's. And if they're all modelled on the GL model then there's little difference between DX and *L - it's just that with Dx there's a single install and with *L there's multiple. Plus with *L there's the choice of not installing the components that you don't need...

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

V-man
01-15-2004, 09:15 PM
Originally posted by rgpc:
But why? They're nothing more than a set of API's. And if they're all modelled on the GL model then there's little difference between DX and *L - it's just that with Dx there's a single install and with *L there's multiple. Plus with *L there's the choice of not installing the components that you don't need...

Developers who use DX probably know GL, but do they know the rest? Probably not.

Have you noticed how DX based games tend to use D3D, DSound, DInput, DPlay?
I'm sure there are plenty of cases that also make use of other libraries instead but in general D3D and DSound are always used it seems.

MS's strategy has worked.

On the developer side of things, I think things are improving. Float buffer is candidate to become core but I think they will settle for an extension instead.
ARB_vp + ARB_fp wont get in the core for sure.


ARB_fragment_program_shadow?
I guess they mean something like this

TXP reg0, coord, texture[0], SHADOW;

GPSnoopy
01-16-2004, 08:26 AM
It's true that all the extension mess + the lack of standard libraries is really awkward.

I mean, for my latest projet I had to use my own extension loader lib, my own image lib, my own math lib, etc...
There are already a lot of libs around the net that do those things, but none of them is fully complete or completly standard.
Finally we end up using a part of them, and for the rest we all reinvent the wheel each time.

IMHO the ARB should work more closely with the whole OpenGL community (and not just ISV) to get feeback, and eventually start dedicated committees/projets.
I think that the C++ Standards Committee (http://anubis.dkuug.dk/jtc1/sc22/wg21/) has nice ideas about the ways of handling the language evolution. For example ANYONE can make proposal about future features and extensions to the language and/or the library.
That way current 3rd party libs, developers, and even amateurs, can discuss and propose ideas (even working and already implented ideas).
The good thing is that the result is generally a merge of all the good ideas and influence, and not just the promoting of one big library. So at the end the final result is more complete and generally suits everyone better.

IMHO the ARB should push the creation of a standard library (or multiple standard libraries) that way.
Personnaly I would be delighted to help them, and I think most of of the people on this forum would be too, wouldn't you?

EDIT: About ARB_query_extension, I think it has nothing to do there. It's a library problem, not an API problem.

[This message has been edited by GPSnoopy (edited 01-16-2004).]

bunny
01-16-2004, 11:45 AM
Extension loading and the outdated 1.1 windows DLL really is a solved problem. Extension loading libraries (like GLee for example), give you seamless support for OpenGL 1.5 and all available extensions. An extension such as ARB_query_extension doesn't really solve the problem directly.

It's a shame this stuff isn't available as standard, but a number of free libraries are available under unrestrictive licenses which do the job perfectly well.

jwatte
01-16-2004, 02:00 PM
Direct3D has better render target support than OpenGL, but worse Z buffer readback support. It also has a single, uniformly supported high-level shading language.

barthold
01-16-2004, 04:20 PM
Originally posted by Zak McKrakem:
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)

Not quite true. 3Dlabs has been shipping drivers with support for (an earlier version of) GLSL since early 2002. 3Dlabs has shipped drivers with support for the official ARB approved OpenGL Shading Language right after the ARB approved these extensions in July 2003.

Now, I can't help it that most of you don't have 3Dlabs graphics cards :-)


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.


Employees of IHVs read these forums, and do answer questions when it makes sense. I don't think you'll ever find such an employee to make a statement about future availability of hardware or drivers etc. It is too competitive of a market to do that. I would like to know too when NVIDIA is going to support The OpenGL Shanding Language :-)

Barthold
3Dlabs