Anisotropic trilinear filtering?

[Stonemonkey]

Hi all, I've not been up to much for a while but just recently I've been having a look at texture filtering again and got some form of trilinear filtering working.

It works by calculating how much u and v changes per pixel length at each vertex (vertical and horizontal changes), chooses the larger of the two values and perspective correct interpolates that across the tri. Then using Log2() I can get the two mipmaps and the value to filter between the two bilinear results from each mipmap.

That's all ok and works reasonably well if a bit slow but suffers a bit from blurring in the distance so I've been attempting to use ripmaps to see if that can improve it any.

What I'm doing now is interpolating both the du and the dv changes across the tri but the changes between ripmaps with respect to u can occur at different points to the changes with respect to v which makes finding the filter value for the two textures a bit tricky to work out.

Does anyone know anything about this problem?

[Jim]

So what you're saying is:

When you use square mip-maps you always know for sure which 2 mip-map levels you are interpolating between, but when you use rectangular rip-maps 'u' indicates to use one pair while 'v' might indicate you should use a different pair?  Sounds tough!

Jim

[Stonemonkey]

Not exactly, I have 1 value for u and 1 value for v so i can get 1 map above and 1 below.

With isotropic mipmaps I just use 1 value so the blending of the 2 mipmaps (assuming bilinear is done) just uses the fractional part.

The problem here is that the fractional parts of the u and v values ar different and they change at different rates so the level with respect to u changes at a different time to the level with respect to v and I have no idea how to work out how to blend the texture samples

[Stonemonkey]

I have something along the lines of this:

Code: [Select]

'p is for u, q is for v

'the interpolated values here are actually log2(interpolated values)*256.0
p_fraction=p_interpolated and &hff
q_fraction=q_interpolated and &hff

p=min( p_interpolated shr 8 , tex_width_bits )
q=min( q_interpolated shr 8 , tex_height_bits )

tex0=texture->ripmap_u_list[p]->ripmap_v_list[q]

p=min( p+1 , tex_width_bits )
q=min( q+1 , tex_height_bits )

tex1=texture->ripmap_u_list[p]->ripmap_v_list[q]


[hellfire]

With mipmaps your calculating one resulting level from both deltaU,deltaV so each pixel is somewhere between two mip-levels.
With ripmaps you you select different maps for different deltaU,deltaV so each pixel is essentially an average of four maps (and you probably don't want to do that in a software-renderer).
However, you probably do perspective correction every "n" pixels and interpolate linearly in between.
So what you've got is one set of (deltaU,deltaV) for each span:

Code: [Select]

  prev   current   next
+-------+-------+-------+
 (du,dv) (du,dv) (du,dv)
From each set of (du,dv) you can extract one ripmap (integer part of the deltas) and a subprecision level for trilinear filtering (the fractional part).
As long as two neighbouring sets of (du,dv) indicate the same ripmap everything is fine and doesn't need further handling.
Otherwise you have to subdivide the current span again and calculate where exactly *one* of the deltas reaches a new ripmap-level (the fractional part of delta[n+1]-delta[n] is 0).
As in this sheme only one level of anistropy changes at a time you just have to interpolate between two ripmaps which is essentially just like trilinear interpolation with mipmaps.

[Stonemonkey]

Thanks hellfire, I'll have to think about this some more.

I'm doing my perspective correction every pixel so I can't do exactly what you're suggesting.

One other thing that I'm a bit confused about, you're only taking the horizontal delta into account but as an example, deltaU could be constant 0 along the scanline and no matter how the tri is scaled that won't change which would mean that even a small tri would lookup the same ripmap with respect to U as a large tri.

[hellfire]

you're only taking the horizontal delta into account but ...

You're right.
For mip-mapping it worked okayish to expect orthogonal  deltaU,deltaV in horizontal/vertical direction, but this of course doesn't make sense when trying to handle anisotropy.
Performance-wise I would try some grid-subdivision-sheme:

Hardware-renderers interpolate mipmaps over larger areas, too, because picking different maps per pixels would kill all streaming predictions.

[Stonemonkey]

I think I'm being stupid.

If the deltas are constant over the tri, even with the perspective calcs the ratio between du and dv should also be constant? (i think)

if that's the case then I can select one ripmap and just use it's mipmaps.

Need to come up with some way of organising the maps for that, including going back up the ripmaps to the original for some cases.

Anyway, thanks for the help.

[Stonemonkey]

Well, it turns out that wasn't the case

So I've come up with something slightly different. It takes 1 sample from each of 3 maps, the current map and the 2 maps below and blends between them using both the du and dv fractions although I think i still need to work on that bit.

As you can see it still has it's problems but it's a big improvement, even over the mipmapping i was using before although it is a bit on the slow side too.

EDIT: Just noticed I can get exactly the same results just from using 3 samples from a single texture.

[Jim]

It's a remarkable improvement and it still runs OK!

Jim

[Shockwave]

It runs surprisingly well on this old box Stonemonkey. Well done.

I've really missed your experiments.

[Rbz]

The difference is very well visible and seems to be working at good speed here.

[Stonemonkey]

Thanks all, I've just been trying to add bi linear filtering but it was quite noticable where the level changes and I can't see any way around that but I'm quite happy with the results of this so I'll see what I can hack away to get it running a bit better. It's only 2 tris filling less than half the screen so it needs to be a bit faster to be useful for anything.