Angus Dorbie (dorbie++at++sgi.com)
Tue, 13 Oct 1998 17:39:34 -0700
Problem 1
_________
The first problem which produces the most glaring errors
is when the levels of MIP are generated, and this may be
the problem you are encountering under minification. The problem
is not so much overlap as where the samples used by the filter
to generate the MIP level are derived from, and the overlap of
the filters used to produce the samples ad adjacent tile borders.
When generating MIP maps for a sample in a small MIP image (high
level of MIP in OpenGL parlance), the 'footprint' of the filter
in the original image is quite large and covers many image
samples in the base image (level 0 MIP map in OpenGL).
If you filter adjacent image tiles independently then the
samples used for the border of the tile would and should extend
beyond the border of the tile and require data from the adjacent
image tiles. However, by processing tiles independently you
have no data there and typically average within the available
data for the filter.
This is the underlying problem. As you can see, the greater the
minification the larger the filter footprint and the more missing
information you have at the border because it only exists in an
adjecent tile. This can lead to obvious image discontinuities
at tile edges which increase in significance and scale as the
texture image minifies. A high contrast feature near the edge
in one tile will at some scale will affect the color of the
edge texels in one tile but not in another causing a sharp
discontinuity.
Because the scale of the problem varies with the level of MIP
due to the varying filter size, the problem cannot generally
be solved for all situations using a fixed overlap. Infact an
overlap is the wrong approach.
Problem 2
_________
The second problem seems to be the one Steve has mentioned
and is certainly closely related and I'm sure he understands
both completely.
This is the issue of the hardware texture filtering even
after you have the correct texture MIP levels generated.
At each level of MIP there is a bilinear filter of available
image samples. There is no filtering of this data between
adjacent texture tiles. With the appropriately clamped
texture repeat filters your color for that sample will
simply stop right at the texture edge and ignore the
adjacent image. Again the scale of this varies with the
MIP level so simple padding the texture and pulling in
the texture coordinates will only work for one level of MIP.
This problem changes in scale with level of MIP in the same
way as the first. With the right hardware it could be handled
correctly with proper edge clamping but that's a complex
subject involving another different MIP level generation
approach. If memory serves me correctly Iris GL used to be
a tad better for edge filtering.
So you'll probably get much better results if you generate
your MIP levels from all available image data to solve the
first problem and problem 2 may be less of an issue on your
lower levels of MIP, but that's already been duscussed.
Cheers,Angus.
Steve Baker wrote:
>
> On Tue, 13 Oct 1998, Nigel Caughey wrote:
>
> > Steve Baker wrote:
> > >
> > > The amount of overlap you need increases as you descend the MIPmap
> > > levels. There is no "right" amount.
> > Is this a linear increment at level 0?.
>
> Well, look at it this way - the texture interpolation process blends
> between adjacent texels at whatever level map you are drawing. If it's
> at the edge of the map, it'll either blend the edge texel with itself
> (if we have GL_CLAMP'ed the texture coordinates) - or with the texel
> on the opposite side of the map. Neither is ideal since you want to
> blend with a texel from a completely different map - and there is no
> way to do that.
>
> So, if you had 256 meter polygons with 256x256 texel maps - then you'd
> have to overlap the texture by 1 meter to prevent the blending at the
> edge of the polygon from pulling in inappropriate data from "off the edge
> of the map".
>
> However, when the polygon goes a bit more edge-on (or further away), the
> map drops to a 128x128 - and now you need a 2 meter overlap (er - roughly).
>
> At 64x64, you need a 4m overlap...and so on. In the limit, the 2x2 map
> has to be overlaid by 128 meters - and now your texture map is all
> overlap and no data.
>
> Ultimately, there is no way to fix that.
>
> Of course in practice, the texels in a 2x2 map are typically all some
> kind of brownish mush - so who cares? But in *theory* you should still
> care if you want perfection.
>
> So, it's a judgement call. At how much overlap and at what polygon
> orientations and size do you judge the mismatch artifacts to be
> unimportant? It depends on the application, and the nature of the
> data in your texture map. A black and white chequerboard with a 4x4
> grid on a 1024x1024 map will be pretty sensitive to error right down
> to the lowest mipmaps. A soft cloud texture will hardly show a problem
> even without overlap (so long as you remember to GL_CLAMP the texture
> coordinates).
>
> However, my point is that there is no use saying "I used 'N' texels of
> overlap - and that's OK" - because there is no solid basis for that
> advice.
>
> Steve Baker (817)619-2657 (Vox/Vox-Mail)
> Raytheon Systems Inc. (817)619-2466 (Fax)
> Work: SBaker++at++link.com http://www.hti.com
> Home: SJBaker1++at++airmail.net http://web2.airmail.net/sjbaker1
>
> =======================================================================
> List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
-- "Only the mediocre are always at their best." -- Jean GiraudouxFor advanced 3D graphics Performer + OpenGL based examples and tutors: http://www.dorbie.com/
This archive was generated by hypermail 2.0b2 on Tue Oct 13 1998 - 17:39:38 PDT