Re: Large textures getting soft

New Message Reply Date view Thread view Subject view Author view

Dewey Anderson (dewey++at++evt.com)
Fri, 30 May 1997 16:33:27 -0600


Thanks to all the replies to my question about large textures. They were very
helpful.

Here's how I see the picture forming:

The call to

  glGetIntegerv(GL_MAX_TEXTURE_SIZE, &imax_tex);

seems to give worst case scenario and so is not necessarily a good indication
of the true limit.

I used the suggested proxy texture (as described in the on-line book "OpenGL on
Silicon Graphics Systems") to see how large a texture I could get away with:

  glTexImage2D( GL_PROXY_TEXTURE_2D_EXT, 0, // LOD level
                4, // color components
                1024, // width
                1024, // height
                0, // border
                GL_RGBA, // format
                GL_UNSIGNED_BYTE, // texel data type
                NULL ); // ptr to actual pixel data
  int tex_width;
  glGetTexLevelParameteriv( GL_PROXY_TEXTURE_2D_EXT, 0,
                            GL_TEXTURE_WIDTH, &tex_width);
  printf(" tex width: %d\n", tex_width );

By playing around with the width and height, I was able to get it to "OK" a
texture of 1024x1024. This should mean that a mip-mapped texture of 1024x512
should fit, since mip mapping should only add 1/3 again the memory requirement.

According to John Risasco at SGI:

>The symptoms of a texture that is too large are that the texture geometry
>will appear a blinding white and glError will report GL_TEXTURE_TOO_LARGE
>for OpenGL 1.0. For 1.1 I heard rumour that this will be changed to
>GL_INVALID_VALUE.

I intentionally went in and made my textures 2048 x 1024 instead and my
PERFORMER application still worked. But the textures were VERY fuzzy.

This would suggest that Performer is stepping into the middle of things to
prevent the OpenGL failure. Apparently if you try to make a texture so big
that OpenGL will choke on it, Performer makes a smaller (filtered) version of
the texture to give to OpenGL. I think this is a fine thing for Performer to
do.

But it looks to me like maybe Performer is getting a little overzealous in its
interference. As far as I can tell, a 512x1024 32 bit RGBA mip-mapped texture
should fit in the texture memory on our systems (Impact with TRAM, Octane SI).
 But it looks like Performer is stepping in and making a smaller filtered
version anyway. Is it possible that Performer is using the value returned for
GL_MAX_TEXTURE_SIZE as its criteria? Any chance of getting it to check a
little more carefully?

Does it sound like I'm understanding the situation right?

Thanks,

Dewey Anderson
dewey++at++evt.com
Evolving Video Technologies

=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
            Submissions: info-performer++at++sgi.com
        Admin. requests: info-performer-request++at++sgi.com
   SGI DevForum 97 info: http://www.sgi.com/Forum97/


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:55:20 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.