I find this extension interesting, specially since its functionality can be simulated with the needed calls to glTexSubImage.
I was wondering what the advantage is of this extension? Is the rescaling function hardware accelerated or it it just a standard gluBuild2DMipmaps.
What I find weird is that it needs to be enabled using glHint? What if someone wants to disable. Why not use glEnable/glDisable on a per texture object basis?
V-man
------------------------------
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);
yes i believe its a lot quicker, glubuildmipmaps calls gluscaleimage which is a very slow image scaler
>>What I find weird is that it needs to be enabled using glHint? What if someone wants to disable. Why not use glEnable/glDisable on a per texture object basis?<<
wouldnt u want it enabled all the time?
from the spec
'TexParameterfv with <target> set to TEXTURE_1D, TEXTURE_2D, or
TEXTURE_3D_EXT, <pname> set to GENERATE_MIPMAP_SGIS, and <param>
set to TRUE (or <params> pointing to TRUE). It is disabled using the
same call, with <param> set to FALSE, or <params> pointing to FALSE.'
i think the hint applys to the resampling method ie nice + slow OR not so nice + quick
You don't have to do the scaling yourself. Good if you have streaming video and need to upload the frames to a mipmapped texture.I was wondering what the advantage is of this extension?
As I always say nowadsys. You don't want to know if it's hardware or software, you want to know if it's fast enough. And you never know how the mipmaps is generated, since it's not stated in the spec.Is the rescaling function hardware accelerated or it it just a standard gluBuild2DMipmaps.
As I understand it when I read the spec, you don't enable/disable it with hints. You enable/disable it with glTexParameter, pname=GL_GENERATE_MIPMAP_SGIS and param=GL_TRUE or GL_FALSE. And since you set it with glTexParameter, you do set it on a per-texture object basis.What I find weird is that it needs to be enabled using glHint? What if someone wants to disable. Why not use glEnable/glDisable on a per texture object basis?
>>>>As I always say nowadsys. You don't want to know if it's hardware or software, you want to know if it's fast enough. And you never know how the mipmaps is generated, since it's not stated in the spec.<<<<<
Agreed, but if it's hardware accelerated for this case, then that means its entirely done on the video card so there is no need to upload via CPU or AGP memory so it should be much faster (unless if the chip implmentation is not great).
Also, since I worked on speeding up the gluScaleImage (from 12 to 150 times faster), it would be cool to have a chip implementation of my version.
V-man
------------------------------
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);
Yes, it's done in hardware on most cards (on ATI cards it's still done in software on Win9x I think, but in hardware on WinNT).Originally posted by V-man:
>>>>As I always say nowadsys. You don't want to know if it's hardware or software, you want to know if it's fast enough. And you never know how the mipmaps is generated, since it's not stated in the spec.<<<<<
Agreed, but if it's hardware accelerated for this case, then that means its entirely done on the video card so there is no need to upload via CPU or AGP memory so it should be much faster (unless if the chip implmentation is not great).
Also, since I worked on speeding up the gluScaleImage (from 12 to 150 times faster), it would be cool to have a chip implementation of my version.
V-man
[This message has been edited by NitroGL (edited 04-01-2002).]
gluScaleImage is a very flexible function, and u just need to take every second pixel if you wan't smaller images for mipmaps very fast.Also, since I worked on speeding up the gluScaleImage (from 12 to 150 times faster), it would be cool to have a chip implementation of my version.
Even when you do filtering, it is a very fast process with the limitation of making the images half size.
By the way, there is something i didn't find in the specs. The behavior of this extension with compressed textures. And at least on my geforce the extension generates mipmaps even with compressed textures BUT its not a scaled version of the base texture, it is an part of it which gets smaller for each level. So if you have a problem with compressed textures looking different on distances, just disable it and generate the mipmaps yourself.
It would be intersting if an ATI Card behaves the same way...or if it is specified somewhere, and i didn't see it.
Lars
Can you send me your application with compressed textures generating incorrect mipmaps? I've tried this and it has worked fine in my experience.
- Matt
Strangely, I found that the 'do it yourself' approach works faster than the extension.
'do it yourself' is NOT in the CPU, but by utilizing the GPU's ability to render textures, limit mipmap level usage, and read back the rendered result to a texture level image.
This is on nVidia hardware, and may have changed with very recent drivers..
Do it yourself in by the hardware using the framebuffer? Well I suppose you can use GL_LINEAR for min and max filter and render a quad and copy back into texture levels. Is that what you mean?Originally posted by Moshe Nissim:
Strangely, I found that the 'do it yourself' approach works faster than the extension.
'do it yourself' is NOT in the CPU, but by utilizing the GPU's ability to render textures, limit mipmap level usage, and read back the rendered result to a texture level image.
This is on nVidia hardware, and may have changed with very recent drivers..
V-man
------------------------------
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);
Hi
Seems that i made an error here, at least i can't get the behavior recreated i described above. So it might be just something wrong with my code back then (like overwriting the miplevels with wrong mipmaps or something).
But it is a while since i got my mipmap generation working with compressed textures (without the extension). And i don't have a codebase with this error, only one before implementing compressed textures and one after, where everything works correctly when i put in the extension instead of my own mipmaps.
So thanks a lot, now i can just use the extension instead of creating all the sublevels myself.
Sorry for the inconvenience
//Edit
I am just curious, does the miplevels get recompressed, or are they uncompressed?
Because it takes nearly no time even when generating mipmaps from a 2048x2048 texture.
Lars
[This message has been edited by Lars (edited 04-02-2002).]
Posting Permissions
