Textures Loading

I think, that Textures Loading Function will be the great idea!!!

In OpenGL, it’s not a good idea. Search this forum for reasons why it’s not a good idea. It’s not like you’re the first one to suggest it.

I dont know if you are right about not a good idea… The reason is really that OpenGL is a graphics API. If you just dwell over that a minute you can proberly figure out that if OpenGL starts handling, image loading, mouse events, loading shaders from files etc the API will evovle in a very different direction. Focus is graphics. But I understand the dilema, actually I am merging slowly to DirectX but that is due to the at times slow development of OpenGL extensions that are keept as extensions for ages (feels that way)

it’s not a good idea for experienced programmers, because they already have their own image libraries.

it is a good idea for beginners, since the last thing they want is to fool with loading a texture. personally i think a texture loading api extension for glu might be a good idea to attract newcomers/lazy/busy. d3dx has this stuff, along with all kinds of math and geometry goodies to hook the newcomers/lazy/busy (d3d will spoil you). it might not hurt opengl to open the doors to the younger/lazy/busy ranks in this respect.

but due to the sheer ubiquity of texture loading code online i think it’s felt by many to be a wasted effort. however i have no objection to an extension of glu services.

regards,
bonehead

OpenGL is not a “graphics library”. It is an interface to 3D rendering hardware. As soon as IHVs start making graphics cards that directly use PNG or JPEG images as textures, OpenGL will have the ability to load them. Until then, it won’t.

Go to SourceForge or Fresh Meat if you need to find an image loading library. There are lots of them with very liberal (either LGPL or BSD-style) licenses.

idr, you say that as if you’ve said it a few times before :wink:

regards,
bonehead

Well I think the point is taken :wink: Still I really understand the dilema. I personally think this is more ideology than common sense, sorry. The image loading is one thing, after some time you write your own code. But the primitiv run-time env. in GLSL is rather pathetic compared to Cg. I understand both sides but the platform indepdencies is really ruined when everyone uses their own special library for virtually everything. Just to make things clear I support that OpenGL is just a graphics language. But you cant really do a lot without all the other stuff :wink:

It isn’t “just” idology. It is a matter of how OpenGL works.

Unlike D3D, OpenGL doesn’t have any library-side code. Every time you call an OpenGL function, you’re calling directly into IHV code. So, if the ARB adds some kind of image loading extension to the API, every IHV now has to implement this code.

Meanwhile, Microsoft can just add it to the D3DX library as a matter of course, because D3DX is purely a library. It does not directly interface with the underlying IHV code, so they just implement it once and it works everywhere.

Unlike D3D, OpenGL doesn’t have any library-side code. Every time you call an OpenGL function, you’re calling directly into IHV code. So, if the ARB adds some kind of image loading extension to the API, every IHV now has to implement this code.
bingo…this wouldn’t make such an extension a pleasant prospect for the ihv’s then (can’t say that i disagree) :wink:

please correct me if i’m wrong…each ihv’s driver implementation optionally overrides sgi’s base implementation to accelerate what it chooses? couldn’t some base implementation of this stuff be made and then simply ignored by the ihv’s?

i have no real vested interest in this (other than genuine curiosity)…and i’m pinch hitting for xorek :wink:

regards,
bonehead

please correct me if i’m wrong…each ihv’s driver implementation optionally overrides sgi’s base implementation to accelerate what it chooses?
No, it does not. A driver implementation must be a full implementation of OpenGL. And, if no ICD is installed, then it defaults to the Microsoft implementation. SGI’s implementation is an ICD.

Also, do note that this method of GL development applies to Windows and Linux. The tight integration of OpenGL into MacOSX allows Apple to make their OpenGL behave more like Direct3D does. They can ask IHVs to implement a different API (with extensions), one that is lower level than what the user sees, and they can sit their own code between the client and the driver. This lets them take care of providing boiler-plate code and allows IHV’s jobs to be easier. Apple could provide image loading libraries without IHVs even noticing.

Such a thing could be done for Win32 or Linux. However, there’s no one in a good position to do this for Linux, and the company in the best position to do it for Win32 (Microsoft) has negative interest in doing so.

thanks korval.

…[edited to reflect current wisdom and reduce storage burden]…

regards,
bonehead

Originally posted by Korval:
It isn’t “just” idology. It is a matter of how OpenGL works.
Sure. Thats is correct and to the point. I agree with you totally. But I think that it as ideology when you owen Shader language does have a proper run-time env. Should DX provide us with that?

well xorek, i believe we’ve been schooled :wink:

it appears that an ihv starts with an implementation (likely sgi’s sample implementation), then proceeds to craft it’s own tailored version such that it’s in accord with the specification. so in asking for texture loading support you’re essentially asking all the ihv’s to implement/adapt and maintain a bunch of new code, not a scenario taken lightly by those concerned :wink:

thanks to idr and korval for clearing this up :wink:

regards,
bonehead

Well bonehead, why not then let the OpenGL standard start its owen library supporting just that… Then OpenGL is keeped clean (as I said I agree). Anyway this discussion is fruitless. Since it all started out with a guy asking for image loading… see the top :wink:

why not then let the OpenGL standard start its owen library supporting just that…
heck, it all boils down to time and economics. given enough time and money, anything is possible :wink:

texture load is very simple .
In a game or other 3D application . you only need ONE or TWO image format(eg. jpeg and TGA). you can write this code within one houre.

Or just use DevIL .
As has been stated already, there are tons of image loading libraries. None of them is “the official OpenGL image loading library”. But that really shouldn’t be a problem. Modularity is a good thing IMO because it allows competition.

Imagine you’d be forced to use the jpeg group’s reference library every time you’d want to load a JPG. What a horrible thought!

Imagine you’d be forced to use the jpeg group’s reference library every time you’d want to load a JPG. What a horrible thought!
I don’t see anyone suggesting that you be forced into anything. But for noodling around and making little demo apps, the JPEG reference implementation would be fine. Performance isn’t an issue.

It’s a place where D3D wins; ease of initial use. It makes it easy to load images from files, load meshes, and all while preserving the sanctity of the core library by providing this external functionality as an external library (D3DX). It is distributed with the SDK, so if you can make D3D apps, you have it. It’s there, and it does it’s job. It’s not what you would use for a real app, but it does serve a purpose.