Scott McMillan wrote:
>
> Oops forgot to attach the source code....
>
> Scott McMillan wrote:
> >
> > I have been playing with scaling the texture matrix and I have
> > come across a weird result on my Linux box running Mesa 3.0
> > (that doesn't show up on my SGI at work).
> >
> > The attached program scales the texture matrix (2, 2, 0), and
> > renders a textured triangle strip with texture coords in the
> > range [0, 1] (the result looks like I have an identity texture
> > matrix with texture coords in the range [0, 2] and I have set
> > clamp.
> >
> > The resulting texturing gets messed up in area outside the normal
> > texture (where the CLAMP causes the edge pixel to be "stretched"
> > across the polygon), but (and this is the good part) ONLY WHEN THE
> > POLYGON GETS TOO CLOSE TO THE VIEW.
> >
> > Can anyone else recreate this in current beta versions (I am still
> > trying to set up CVS at home)? If so, is this a bug or just an
> > area outside of the spec?
OK, I figured it out. It's not really a bug with respect to the spec.
However, it's an area where many GL implementations don't exactly
follow the spec. For example, I tested on an a few SGI systems:
Indigo2 IMPACT: output matches Mesa
Octane MXI: output matches Mesa
Onyx IR: no gray pixels
O2: no gray pixels
I didn't test any NT-based cards as this was enough to confirm my hunch.
Here we go...
First of all, the reason the gray pixels appear only when the polygon
gets close is that you have different filters for minification and
magnification. The gray is seen when magnifying with GL_LINEAR, but
not minifying with GL_NEAREST. If you used the same filter for min
and mag you'd get consistent results as the polygon changed sizes.
Now, pull out your copy of the OpenGL 1.1 spec and go to section 3.8.1
(or section 3.8.5 in the 1.2 spec).
Here's the steps for choosing texels for GL_CLAMP, GL_LINEAR mode.
Ignore the second texture dimension for brevity.
Let texture width = 64 (per your demo program)
Let n = 6 since 64 = 2^6
Let s = 1.0 (any value >= 1.0 will show the problem)
Clamp s to the interval [0,1]
Let u = 2^n * s (per the spec)
= 64 * 1.0
= 64.0
Let i0 = floor(u - 1/2) (per the spec)
= floor(63.5)
= 63
Let i1 = i0 + 1 (per the spec)
= 64
Let tau0 = Texel[i0]
= Texel[63]
= (0,0,0,1) = black (or orange, from your texture image)
Let tau1 = Texel[i1]
= Texel[64] !! [63] is the rightmost texel in your image.
tau1 refers to a border texel. The default border color is (0,0,0,0)
After blending tau0 and tau1 (per linear sampling) we end up with a
final texel color of (0,0,0,0.5)
Using GL_DECAL mode, we modulate that with the underlying polygon
color of (1,1,1,1) and end up with the color (0.5, 0.5, 0.5, 0.5).
That's the gray you're seeing.
The behaviour you really want is GL_CLAMP_TO_EDGE which is available
in OpenGL 1.2 and as an extension to OpenGL 1.0 and 1.1. This mode
prevents border texels from being sampled.
However, I believe quite a few existing OpenGL implementations implement
GL_CLAMP as GL_CLAMP_TO_EDGE. In this example, i1 would have been
clamped to 63.
My policy in Mesa has been to follow the spec as closely as possible
so I'm unlikely to change it to make it behave like other OpenGLs.
I bet that if the OpenGL designers had a second change to design
OpenGL they'd leave out texture borders completely. They seem to be
more trouble than they're worth.
BTW, the texture modes you're using put you on a very slow path
through Mesa. There are quite a few functions calls per pixel.
-Brian
----------------------------------------------------------------------
Brian Paul Avid Technology / Softimage [EMAIL PROTECTED]
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
