RE: [Algorithms] mip mapping is evil!

[Tom F. <tom...@ee...>]

Anisotropic filtering is actually (a) pretty good and (b) works with =
mipmaps
very well.

There's a bunch of different ways to do it, but here's a common way (not
sure how hardware actually does it, but this is going to be fairly =
similar).

You take your screen pixel and you project it onto the texture. This is =
some
sort of four-sided shape, though because of perspective and suchlike, =
it's
basically a mess - none of the sides are equal or parallel.

First approximation is you remove the effect of different perspective on
each side of the quad, so now you have a parallelogram - pairs of sides =
are
parallel, but not equal length.

Second approximation is that you find the longest length inside this
parallelogram. Most of the diagrams show a parallelogram with two long =
sides
and two short sides, and say that you pick the long sides, but this is
misleading, because there is also the case of a squashed diamond shape - =
all
four sides the same length, but it's been squashed. Both these cases do =
work
(I believe), but the intuition above gives you the wrong idea.

OK, so you have the longest length inside the shape, which is the axis =
of
anisotropy. You also find the width of the shape at right-angles to this
axis. Now draw a rectangle around this shape, and that's a bit like the =
area
to be sampled.

The way most hardware does this (I believe) is by selecting the mipmap =
level
so that the width (the shorter measurement) is one texel in size. Then =
take
multiple trilinear samples along the longer edge, each two texels apart.
Take as many samples as needed to fill out the length. So obviously if =
the
two lengths are the same, and the shape was basically a square, the =
hardware
only needs one sample. If the shape was twice as wide as it was long, it
needs two samples, and so on.

Nominally, the mipmap level chosen is a fractional value, so that each
sample is a trilinear sample. I suspect hardware does it slightly more
efficiently here, since otherwise you're doing a lot of separate samples =
in
the lower mipmap level that you probably don't need to do.


So it's not actually that bad. You are first approximating the real =
shape
with a parallelogram, then approximating that by a rectange, and then
approximating that by a bunch of trilinear samples. But the end result =
isn't
all that far off the right one. Usually :-)


TomF.


> -----Original Message-----
> From: gda...@li...=20
> [mailto:gda...@li...] On=20
> Behalf Of Rowan Wyborn
> Sent: 07 January 2005 13:42
> To: gda...@li...
> Subject: RE: [Algorithms] mip mapping is evil!
>=20
>=20
>=20
> > However, there are still problems.  If you imagine a four=20
> > texel 1D texture.  What you'd like
> > to have for the realtime display of that texture would be one=20
> > MIPmapped texel that summarises
> > the results of filtering a region that's two texels across=20
> > centered between texels 0 and 1 and
> > another centered between 1 and 2, another between 2 and 3 and=20
> > so on. However, you don't have that.
> > You only have a single filtered RGB for the region between 0=20
> > and 1 and another between 2 and 3.
> > So if the screen pixel covers two texels and is centered=20
> > between texels 1 and 2, the hardware
> > is forced to do a linear interpolation between the 0/1 texel=20
> > and the 2/3 texel.  This does indeed
> > throw away some information that could have been preserved.
>=20
> Yes, this was the issue i was referring too when i said=20
> 'throwing away detail'... this is what makes mipmapped pixels=20
> look much blurrier than they should be.
>=20
> I think anisotropic filtering is probably the only practical=20
> solution, hardware is already somewhat capable of it (for a=20
> perf hit)... perhaps sometime in the future cards will no=20
> longer even support bi-linear filtering, and fast anisotropic=20
> will become the standard :)
>=20
> rowan
>=20
>=20
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_ida88
>=20