My Suggestion

I dunno if this’ll make sense, but I suggest that OpenGL define its own image file-format.

Because of … ?

well, since OpenGL is designed to be cross-platform, then a cross-platform image specification would help much, would it not? This would also help programmers not have to study how to load different image files.

Just a thought… .

Image formats do not belong to graphic API’s IMO. There are also several platform independent formats available with free libraries for loading that you can just include in your project. Png and jpg are pretty good and have free libraries available.

well, how about OpenGL’s own 3D file format then? like that of what Microsoft created (.X file format)…again, just a thought…

A 3D file format is even worse. Images are one thing, they store image data, and this data is more or less common between all formats. Either it’s index mode, greyscale, or RGB/RGBA. Different format stores the actual data in different ways, like raw data, or compressed. But in the end, the data itself, in uncompressed more is more or less always the same.

But when talking about 3D files, there are WAY more stuff than just vertices. There are normals, colors, multiple sets of texture coordinates, materials, smaller sub-objects, transformations for each sub objects, and all kind of skinning information, and more. And if the file format is going to be of any use, it must support a wide range of applications. Now, remember that games/demos/entertainment is a small part of OpenGL’s market. There’s the industrial marker, scientific, medical, design, construction, and lots of other markets. In other words, more or less the whole proffesional market. And a single file format for all of these markets is not going to work.

D3D was targeted for one single market, the entertainment market, and the .X file format was therefore also meant for the entertainment market. If you are targeting a smaller market, like the beginner gamers market, you have a lot easier to find a suitable file format. And I say beginner gamers, case I have not yet seen a proffesional production using .X files. They all use their own format.

.X files are also not a part of Direct3D, which is what OpenGL must be compared to. .X files is something you find in D3DX, which is a helper library for D3D, similar to GLU/GLUT. And as Humus said, files does not belong to the graphics API (which is OpenGL and D3D). If it belongs somewhere, it belongs to the belper libraries, which is exactly where those .X files are located in the DX world.

[This message has been edited by Bob (edited 05-13-2002).]

whoa, hold your horses Bob…'twas just a suggestion…

well, ok, so image fileformat is a no-no, 3D file-format is a worse no-no, then how about voxel as a primitive type? as in, you could use codes like:

glVertex3f(0.0f, 0.0f, 0.0f);

where each vertex is the middle part of the volumetric pixel (voxel)…and then OpenGL could use some states to set the default size of voxels…

so how about this then? voxels…it could be use in games, scientific research, terrain, rendering of human bodies, etc.

how about this?

So what’s the difference between that and glBegin(GL_POINTS)?


well, points render in a square shape, voxels may or may not…althought its name suggests it, volumetric pixels may be, say, spheres, to show a much mroe realistic rendering.

am i making sense? if not, then i’ll stop putting suggestions here… .

spheres wouldn’t be good, because it shouldn’t cover an area if you put alot of them together… a cube should be better… and you can define a cube in a Displaylist and then put it on the screen so many times you want… and there you have the same simulation of voxels that the cards are able to today… so i dont se the use of it at the moment.

but dont stop posting suggestions just because i dont se the use, somebody else maybe looks at it different… maybe some HW creator.


well, the sphere was an example, it could also be a 12-sided primitive…its main use is probably in the world of rendering stuffs in close-up view…and then being able to zoom-out and get the normal view…imagine zooming in on an ice, then seeing its crystals up-close, then zooming out, then selecting another object, then seeing it up-close, and so on…

i hope this makes sense…

i may be wrong but i’ve seen here a news on openGL image format… i don’t remember when or where (excepet that that was on so you may look that way

There is no OpenGL image format so you can’t have seen the news about it.


I’ve found what I was suggesting, it’s an extension, it’s called volumetric textures…it’s like textures put on top of each other that can form a solid 3d model or anything that you want…

so what do you think? why can’t this be included?

3D textures are a part of OpenGL core.


oh…you mean like 1D, 2D, 3D textures? I think the extension is different…i’ll check it out and post what i find out…

3d textures aren’t more of a format than 2dTextures… you are talking about a format like jpeg, tiff or such a thing i guess, but 2dTexture is an 2dArray of raw data, and all other properties (width, height, bitdepht) must be known when you send that array to the card, and the same counts for 3dTextures, difference is that a 3dTexture is a 3dimentional array of raw data.

Anyone here live in the UK/EU? Perhaps there are enough to start up a UK/EU specific group?

Not to take anything away from here of course, its very good here, just a thought.

Well isn’t OpenML suppose to address the needs of a standard video, audio, 2D & 3D format? That would lead me to think that a standard image format would be included in there somewhere. Even though OpenML doesn’t have really anything to do with OpenGL, I can see a day when, since both boards consist of the same members, that they’d eventually migrate the 2 together. Kinda like Direct3D and DirectInput.


Oh please no! The current state of the boards is acceptable and makes sense. As soon as messages are put in the same bucket then I’ll have to go through 100 s of messages about nothing.

OpenML, DevIL and otehr packages are welcomed but should have their own boards.