Dirk Luesebrink (crux++at++artcom.de)
Thu, 29 May 1997 12:40:03 -0400
man pfTexture:
PFTEX_GEN_MIPMAP_FORMAT
Specifies whether or not MIPmap level should be
automatically created for a texture if a MIPmap
minification filter is in use. The default value is
TRUE.
i dont know how that relates to you app, but it could explain the the
blur you see.
dirk.
Dewey Anderson wrote:
>
> I sent this last week but didn't see it show up in the mail. I'm trying again:
>
> OK, this one's got me stumped.
>
> This is compiled under IRIX 5.3 with Performer 2.0.2 and run on an
> Octane SI with texture option, IRIX 6.4, Performer eoe 2.0.4 or
> High Impact with TRAM option, IRIX 5.3, Performer eoe 2.0.
>
> Our application has a problem with large textures (1024x512). I've written a
> small program that does much of the same Performer stuff as our big application
> but I can't get the problem to occur there. Obviously our application must be
> doing SOMETHING different but I'm having trouble finding it. Maybe someone can
> give me some ideas of what could cause this.
>
> The problem is that textures that have a dimension of 1024 come out soft, as if
> they've been filtered. I've got two rectangles with textures on them. The
> rectangles are 511x486 and 720x486 in size and have textures applied to them
> that are 512x512 and 1024x512 in size respectively. I'm setting the texture
> coordinates so that one unit of texture = one unit of rectangle = 1 pixel on
> the display.
>
> The test textures are vertical white stripes on clear black. I draw the
> rectangles so that they overlap (large above smaller) and the white stripes
> line up.
>
> The problem is that the larger rectangle appears to have been filtered,
> softening the edges of the white stripes. This is clearly visible where the
> rectangles overlap and the fuzzied stripe of the big one aligns with the crisp
> stripe of the smaller. I have used the debugger to look at the data being sent
> to Performer for the texture (in pfTexture::setImage) and there are no soft
> edges. Pixels are either (253,253,253,255) or (0,0,0,0).
>
> I first thought that there was some limit in Performer, OpenGL or the texture
> hardware that said "If you get a texture 1024 in size, make a smaller filtered
> version of it instead." but then I tested this with a simple Performer test
> program. This program does nothing but draw these rectangles (with a little
> DCS translation animation) and both rectangles are crisp. Where the rectangles
> overlap, you can't tell where one ends and the others begin. The stripes are
> identical.
>
> I should mention that in our big application, the texturing of the two
> rectangles is done in the same code, i.e. a function is passed the texture and
> the size info and builds the rectangle. This means the problem is not that I
> have one setting for the textures on one rectangle and a different setting for
> the other (except size).
>
> Also, our application does a lot of regular OpenGL drawing (& motif stuff), but
> when it comes to drawing these rectangles, that's pretty isolated as "Draw
> Performer Scene".
>
> And I also tried our application with a rectangle 1024x64 and this was also
> fuzzy. So it's the dimension of 1024 that's triggering it, not total texture
> memory.
>
> Can anybody think of what could cause this? If you WANTED to have something
> that automatically filtered larger textures, can you think of anything you'd do
> to make it happen?
>
> Thanks for any help.
>
> 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
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:55:19 PDT