can someone point me to a site where i can find these. i tried out the glu2DMipmapLevels function in VC++ and am getting a LINKING error to this particular function.
im using the standard files provided by WinXP and VC++ 6.0 currently.
any idea if this can resolved by getting the latest versions of the .libs and .dlls for GL??
TIA,
nishal.
without wanting to annoy anyone but this is quite unbelievable… why oh why does this question occur so often? Do people never read or search before posting? Apart from that, this is mentioned in about every single OpenGL tutorial that exists…
there is NO up to date opengl32.dll /.lib on windows systems.
write one and the world will be a better place 
.
Or use linux.
Or stick to OpenGL 1.1, you will gain the advantage of your program running on really old, really expensive sgi workstations .
Jan
I’m sure it doesn’t help that glu2DMipmapLevels isn’t a valid function… 
Try gluBuild2DMipmaps.
ok, after a whole days searching, i managed to find the latest GLU 1.3 lib and dll. no more linking errors, but there is a memory access fault. any solutions??
One more question, does gluBuild2DMipmaps create texture objects for each of the MIPMAPS it generates from the base texture? i basically wanted to conserve some memory thinking that it does, and if someone wanted to run my app. on a graphics card with lower mem, i thought it would improve performance by making the lower res. textures resident and avoiding the extra higher res. textures. so was the assumption right or wrong??
also the redbook had gluBuild2DMipmapLevels listed in it (OpenGL v1.1). well, im not sure if it is actually part of it or not. if not, can i access it by using extensions as in requesting the runtime proc. address of the function in my driver if it is actually supported by the driver??
TIA, nishal.
there is an extension for generating mipmaps which is a lot better than gluBuild2DMipmaps, SGIS_generate_mipmaps, which does this hardware accelerated, and also, the glu function has a bug (maybe you just discovered that bug , sometimes it crashes), which is also avoided by this.
I would guess that the glu function as well as the sgis extension creates one texture image for each mip mapping level, just as creating them manually (which is what glu… does).
If you want to avoid the highest resolution mipmap level it’s easiest to start with a lower res base texture… check the amount of graphics memory and if you find it is not enough, simply scale down the texture when loading and creating the texture image.
Jan
[This message has been edited by JanHH (edited 12-30-2003).]
>>>the glu function has a bug<<<
What’s the bug exactly?
I think there was an extension that allowed you to create a subset of the mipmap pyramid.
I don’t know what the bug is but sometimes the function gluBuild2DMipmaps crashes… so it did in our program (which is commercial, so it mustn’t crash), and I changed it to the sgis extension, and it works fine.
Jan
well, i dont know if gluBuild2DMipmaps has a bug or not, caz I’ve been using that for quite some time now on 2 NVIDIA cards and it never did crach for me. the crash occured due to the gluBuild2DMipmapLevels. im assuming that the crash was due to the .lib and .dll not conforming to each other. anyway, still not sure about anything, so ill give the SGI extension a try.
what i dont understand is that GLU gives the option to create the MIPMAPS from the base texture - lets assume that that GLU creates 1 texture object per MIPMAP (including the base texture), but then what we have in hand is only 1 handle which corresponds to the base texture object.
now what if i wanted to delete that texture object and all its MIPMAPS, this seems to be conflicting. im not sure if there is a function in GLU to do that!! so when i use the GL function glDeleteTextures i will only be deleting the base texture, and the rest of the MIPMAPS of that base texture will still reside in the GL pipeline (may be system mem. or even worse the AGP mem.).
another thing that puzzles me is that when we use glBindTexure and give the texture objects handle, we use the base textures handle. if MIPMAPPING is switched on, where in the pipeline does GL do the substitution for the glBind to obtain multiple textures for a given poly that spans say more than one of those MIPMAPS?
from the above, the only sense i can make is that MIPMAPS of a given BASE texture do not actually get texture object handles of their own, GL must be doing something else to actually handle MIPMAPPING as a separate case.
for example, what i tried is the following…i used only the default glTexImage2D function to load a texture into a texture object into the pipeline. next i switch on MIPMAPPING using the glTexParam… function. then i run the code, and it totally surprises me. if what we thought was right, we should have atleast got the base texture displayed on the poly when the size (area) of the one texel is greater than the area of one pixel on screen. hence if we went really close to the poly, making sure that the screen resolution is pretty high, we will reach the above mentioned condition, and the base level texture would have been displayed using the MAG_FILTER that we assigned to the pipeline. but all i see is blank (gray) polys getting displayed no matter how close of far off the polys i was.
any explaination or insights to this experiment??? would be great if someone with pipeline experience would shed some light on this topic.
TIA, nishal.
Maybe it will help if you imagine how to set up mipmaps on your own, i.e. create the downscaled image and create the texture objects one by one using glTexImage(…). And then, imagine that gluBuild2DMipmaps does just the same. I think if you delete the texture id, it will delete the base texture plus all mipmap levels that are created. Don’t worry…
Jan
You don’t create multiple texture objects for mipmapping, you have multiple texture images in one texture object…
And if you activate mipmapping, you have to supply every mipmap for it to work, you can’t leave out levels that you think you don’t need, thats why you see nothing in your experiment.
[This message has been edited by Overmind (edited 12-31-2003).]