OpenGL meeting notes

[ben6]

http://www.opengl.org/developers/about/arb/notes/meeting_note_2003-03-11.html

[Runitai]

NV_fog_distance
Gives more app control over computing fog distance, including supporting true "eye radial" Euclidean distance. NVIDIA isn't actually advocating this; old functionality by today's standards. Dropped from consideration for the core, due to lack of interest.


Gee, guys, if it's old functionality, doesn't that mean it damn well better be in the core?

[pcchen]

Why? I'd prefer using vertex program for this.

[Runitai]

well, seeing as glFog commands are really just a high level interface to a vertex program (what libraries are for, getting us away from the details of poly-fill routines and the like), adding a radial fog mode in addition to the exponential and linear modes available now would be a good thing for ease of use.

I, for one, do not feel amused or proud of myself for conquering an API with an obfuscated interface due to lack of features. Rather, I am merely annoyed at the time wasted. I mean, the idea of everyone who uses GL having to write their own radial fog program or find one on the Internet seems silly for something that is obviously a widely used effect.

[pcchen]

I don't think it's a "widely used effect." If so, it wouldn't be dropped due to "lack of interest."

Furthermore, the whole idea of programmability is to replace many "features" with a single programmable interface. So it looks unwise to put it into the core.

[Runitai]

I thought the whole idea of programmability was to allow developers to come up with their own custom effects, not force them to reinvent the wheel for all the standard ones.

Perhaps I am misunderstanding what "core" means in terms of OpenGL. I'm thinking if it's left out of the core, there will be no way to do it without writing your own vertex/fragment program. While this would be fine for one or two features, it would be quite annoying to have to write your own vertex program for lighting, fragment program for alpha blending, etc. If they're leaving things out like radial fog, what else must they be leaving out?

Does the core encapsulate everything in the base distribution of the API, or is it reserved to describe functionality that must have a hardware implementation in order for said hardware to claim OpenGL conformance?

[pcchen]

I thought the whole idea of programmability was to allow developers to come up with their own custom effects, not force them to reinvent the wheel for all the standard ones.

Well, not exactly. For example, there is no new extension proposed for per-pixel lighting. That means you have to do it using pixel shader by yourself. I believe many people need per-pixel lighting more than radial fog. If radial fog is in, why not per-pixel lighting? (actually there are extensions for per-pixel lighting, but not widely supported) However, if you want to bring all "interesting" features into OpenGL, you'll end up a very huge feature set and a huge API. Look at the number of OpenGL extensions. That's why we need OpenGL 2.0.

Perhaps I am misunderstanding what "core" means in terms of OpenGL. I'm thinking if it's left out of the core, there will be no way to do it without writing your own vertex/fragment program. While this would be fine for one or two features, it would be quite annoying to have to write your own vertex program for lighting, fragment program for alpha blending, etc. If they're leaving things out like radial fog, what else must they be leaving out?

Except ARB extensions, there is no "optional features" in OpenGL. That means, theoretically, every implementation has to support every core features, since there's no way to tell which core feature is supported. You can still use extensions if you want (NV_fog_distance in this case).

[bloodbob]

Ahahaha HLSL is in hehe no cg :)

[elchuppa]

and Cg are identical languages (I think). Anything written in Cg is HLSL compatible, the only difference is that nVidia's Cg compiler can compile down to DirectX or OpenGL.

[bloodbob]

I thought cg could only be compiled into OGL 1.x and anyway ogl 2.0 is far from complete so that statement could very well not hold true.

[nooneyouknow]

and Cg are identical languages (I think). Anything written in Cg is HLSL compatible, the only difference is that nVidia's Cg compiler can compile down to DirectX or OpenGL.

CG is not identical to HLSL. They are not compatible. CG can compile down to OGL but how effectively? We know that it is not very effective on PS hardware, so doubt it compiles to OGL very well. MS has the best compiler guys, not Nvidia. Plain and simple.

[Tahir2]

Ref: CG

NVIDIA has the best compiler for NVIDIA hardware?

[nooneyouknow]

Ref: CG

NVIDIA has the best compiler for NVIDIA hardware?

If both are outputting standard PS ASM code, I would still believe HLSL will do better. CG might just provide better Nvidia-optimized ocde.

[Tahir2]

There is nothing standard about CG! ;)