what's the opengl philosophy?

[Brolingstanz]

greetings to all,

it's my understanding that opengl implementations must implement the entire set of functionality defined in the spec (including glu). why is this so?

wouldn't it be *easier* if someone (sgi?) provided a common base implementation for all the boilerplate code that's not really on the fast path anyway, freeing driver writers to focus more on time critical/novel areas of the api, and perhaps even opening the door to a more agressive expansion of glu services?

all comments are welcome :-)

curious,
bonehead

[dorbie]

There have always been extensions outside the core but there are now optional extensions that form part of the 'core' called the ARB extensions that change this situation.

There is a difficult ballance between ease of implementation and features. Conformance tests don't always test for exacting matches and the spec is written to give some leeway in important areas. You can also fail some conformance tests and still pass, just not any of the mustpass tests.

In addition there is the khronos group with OpenGL|ES that deleted a lot of the legacy cruft out of OpenGL so it could be easily implemented at minimal size and complexity but with useful core functionality for mobile devices.

When OpenGL was created in needed enough core functionality everywhere to be useful and get adopted as an API, it also needed coverage for IrisGL stuff (and it didn't initially deliver). The consequence if you don't is you end up with a lowest common denominator getting used and most other stuff becomming vestigial.

Nowadays with two big vendors slugging it out in the PC space the picture looks difefrent but just look at the calls for new features with as much commonality between graphics cards. People are desperate for this, it's almost all they ask for.

P.S. SGI does this, it's called the SI, the standard implementation, it is now open source, http://oss.sgi.com/projects/ogl-sample/ and includes examples of adding hardware acceleration, although it has a reputation for being slow on the software side. Implementations have matured well beyond this or have been built from the ground up. Implemenattion is still a daunting task.

[Brolingstanz]

thanks dorbie.

the question of why a texture loading facility couldn't be introduced in glu came up in the suggestions forum, and i couldn't quite grasp why something like this couldn't be added with relative ease.

as i understand it now, this would force the ihv's into implementing this functionality, even if it only involved glu. that is, any and all glu functionality must be implemented by the ihv.

thanks,
bonehead

ps. thanks for the link.

pps. things are much clearer now ;-)

[Jan]

Why are you always talking about glu ??? glu has nothing directly to do with OpenGL, it is an utility library, which AFAIK never gets updated and is not part of the OpenGL driver.

Jan.

[Brolingstanz]

jan, thank you for your comments.

am i to understand it then that glu is not part of the ihv's implementation? and if such is the case, is it not possible to expand its functionality without impinging on the ihv?

well, it seems that it is indeed part of sgi's sample implementation. it seems that it provides utility services. my question would then be why haven't these services been expanded? has glu been depricated?

my guess here is that the major ihv's have spent considerable time and effort building an implementation from the ground up, and have neither the motivation nor resources to mount an expansion campaign for glu. and as such an expansion would only benefit a relatively small and powerless audience, there's really no mystery here in that respect.

i'm just trying to understand the basic orgianization to opengl and its constituent parts. i like to see the forest before the trees. in d3d, things are very different.

to give this question some context, a question came up in the suggestions forum regarding a texture loading extension to opengl. in trying to explain why this is not possible, it seems that i've unwittingly opened a rather large and distasteful can of worms ;-)

thanks,
bonehead

[dorbie]

There are several areas that OpenGL intentionally avoids. Windowing and file loading being two obvious ones.

These are left to platform and application specfiic code.

Why should a low level API support loading functions? That is firmly in the domain of the application. It would end up favoring a few image formats if it did and we'd be probably be stuck today with a quirky mix of available formats. If you load image formats why not load 3D formats? Of course this is even more firmly in the domain of application including the definitions of in memory data structures.

glu can help by building MIP maps but it's really not the job of OpenGL to load files for you. Libraries to do so are readily available.

D3D is a mess, it has a vestigial retained mode rendering support that can load files but nobody uses it seriously. I heard they will be retiring this API with Longhorn.

[Brolingstanz]

thanks for your comments, dorbie.

There are several areas that OpenGL intentionally avoids. Windowing and file loading being two obvious ones.

this makes a good deal of sense if opengl is to remain platform independent. otherwise i imagine it would fall under the purview of either sgi or the ihv's to implement all the platform specific details...utterly phantasmal :-)

Why should a low level API support loading functions?

why indeed and this cuts to the quick. opengl's objective is to provide low level, platform independent 3d rendering...i get it now :-)

glu can help by building MIP maps but it's really not the job of OpenGL to load files for you. Libraries to do so are readily available.

an instrument has yet to be invented to measure the totality of my agreement with this statement :-)

D3D is a mess, it has a vestigial retained mode rendering support that can load files but nobody uses it seriously. I heard they will be retiring this API with Longhorn.

hmmm...no comment :-P

this is exactly the kind of answer i was looking for. opengl's philosophy is much clearer now.

wow, i can be a bit thick at times. i guess that's why everyone calls me bonehead... ;-)

many thanks,
bonehead

[V-man]

Originally posted by bonehead:
greetings to all,

it's my understanding that opengl implementations must implement the entire set of functionality defined in the spec (including glu). why is this so?

wouldn't it be *easier* if someone (sgi?) provided a common base implementation for all the boilerplate code that's not really on the fast path anyway, freeing driver writers to focus more on time critical/novel areas of the api, and perhaps even opening the door to a more agressive expansion of glu services?

all comments are welcome :-)

curious,
bonehead

The GL philosophy is that it must run. Where or how it runs is of no importance.
Personally, I beleive that this should be changed. There should be a clear difference between hw and sw rendering. For the most part, it's not a problem, but still, I welcome that change.

GLU is not part of OpenGL. It went through 4 updates by SGI and then they stopped.

There use to be a sample implementation provided by SGI. I no longer know what ARB members are doing, but I think they work on their drivers independently. For GLSL, 3DLabs provided a sample compiler.

I disagree with Dorbie. D3D is not a mess for that reason. Retained mode has been dropped a long time ago.

[Brolingstanz]

v-man, thanks for the input.

There should be a clear difference between hw and sw rendering.

this was the area of my confusion. as i'm sure you know, d3d has d3dx for all the utility stuff and so i naturally though its counterpart would be glu in opengl. but apparently this is not a very good analogy at all. since the foremost goal in opengl is low-level, platform independent, hardware accelerated rendering (as i understand it now), i suppose the lack of attention to a utility library (software component) is understandable...it just struck me as a little odd initially. i'm feeling better now :-)

D3D is not a mess for that reason.

hehe...i agree, but i didn't want to go into a big song and dance about relative merits of d3d in an opengl forum, for practical reasons of self preservation, and out of respect for this forum's moderator ;-)

by the way, i really like opengl. the api is extremely clean, consistent, and easy to follow. context initialization is a breeze and one couldn't ask for a better reference than the spec. i'll be porting a project to linux before too long, so i'm looking forward to a more vigorous examination of all this stuff in the near future.

thanks again,
bonehead