Different filtering methods

[Scott C]

Of course none of this is linear, but the multiples are constant throughout Region A or Region B, which is what we are after.

Uh, did you read my post? That's what I was getting at later. Two points:
The bilinear / trilinear ratio is constant (as you say in the above quote by different words).

Yes, I was bringing up the point again that we have to be careful about the linearity and can't translate the trilinear vs bilinear argument to "real" units of texel fetches per pixel because of the nonlinearity combined with the dependance on the geometry of the scene. We could do it for a single infinite plane stretching to the horizon, though.

Its a flaw in the "rectangle with trapezoid screenspace regions" argument here. What if its an infinite plane? Then the regions don't shrink in size. What if the object does not start close enough to have a region that is bilinear or with the 1.25 ratio?

Scott C wrote:

In this case, Trilinear covers EXACTLY 5x the texel area per filtered pixel. At every point, it samples the bilinear filter texel area plus the next more detailed mip level, which is always 4x the detail in texel count. Bilinear filtering is not defined as sampling the "closest" mip level, but rather the mip level that is less than or equal to the screen LOD.


Check some games, and you'll find that isn't the case. Compare bilinear and trilinear here. This was also the topic of discussion above.

Those games then are changing their LOD bias and introducing aliasing.

If Bilinear is doing LOD bias, and trilinear is not, then our whole argument is thrown out because the 4:1 ratio does not hold. Trilinear effectively increases the detail without adjusting the LOD bias and introducing aliasing.

"Region B" for Bilinear may be "Region A" for trilinear on the same object due to the LOD difference.

Thus Hyp-X's diagrams are correct. BTW, n is 2 times the LOD. In your redrawn diagram for trilinear, you just divided everying by 2.

You didn't read my post. My units are in AREA. Each mip level is a factor of 4 apart in AREA. The first diagrams also had the ratio of 4. N = 1 is the optimal 1 texel maps to 1 pixel point. Any larger number = more texels in the pixel = aliasing. But actually, the nyquist criterion is that you sample at 2x the frequency you are trying to measure. In this case that would mean n (area) = screen pixel area /4.

This means that I was incorrect in my diagram, I didn't shift the regions far enough to the left!

It also means that the "more detailed" trilinear map is at most, = to the screen resolution.

I don't have time to redraw them now, but the ratio is still 5. The whole "1.25" ratio bit only appies to a specific LOD change between trilinear to bilinear.


I'll respond to your assumptions:

First many objects are in the distance, and it can't be said that the required mip levels don't fit in cache for these. In other words, the whole texture mip pyramid need not fit in cache, only the sub pyramid for the object. Only a certain fraction of the screen is made up of large objects (in screenspace) that have large textures.

In my assumption, either the majority is "close up" in which case there is a lot of bilinear filtering at max texture detail, or the scene is transitional (walls and floors extending away) where the anisotropy will adjust down the LOD quikly to easily cacheable mip levels.

Frequently close-up objects (foreground) usually have more, varying smaller textures.

Also, my 1K for a couple scanline calculation was wrong because of my improper LOD <>texel count calculation. It would be nearly 1/4 as much required for trilinear, meaning that even the TNT's 4K texel cache could fit a tile or two's worth of required texels in cache.

I'm inclined to say that we are groosly underestimating the effectiveness of the cache in today's environment because of two factors:

1: most surfaces create anisotripic LOD to pixel mappings, and trilinear / bilinear just go for the least detailed of the two screenspace dimensions. This decreases texel density per pixel and makes it even easier for sub mip pyramids to fit entirely in cache.

2:Newer GPU's support high anisotropy levels, and anisotropic filtering would require larger caches, thus, trilinear and bilinear on today's hardware probably caches amazingly well even across several tiles, so long as its the same surface of course.

I agree that the bandwidth difference in real life is probably on the order of 2 or slightly more.

 

[Mintmaster]

Have you been reading the above posts? Of course none of this is linear, but the multiples are constant throughout Region A or Region B, which is what we are after.

Uh, did you read my post? That's what I was getting at later. Two points:
The bilinear / trilinear ratio is constant (as you say in the above quote by different words).

I know you did. I'm just saying that we already established this earlier. No need to bring it up again and state the same things over again.

Its a flaw in the "rectangle with trapezoid screenspace regions" argument here. What if its an infinite plane? Then the regions don't shrink in size.

Again, I'm talking about average cases, and again, we already discussed this. In my previous post:

... the area weighting I assumed doesn't always hold true. A far away building may cover a large part of the scene and use a fairly small mipmap, but when close it won't multiply in area like a road sign because half of it will be off the screen

In essence, this case is your infinite plane viewed along its normal.

The point is most of the time you don't have an infinite plane. Even walls viewed along their normal will usually get occluded in the distance by other walls, such as my stack of road signs example, or corridor example. An infinite floor (provided the horizon is visible) will only scale in area by 1/2 each mipmap, but there are nearly always walls/mountains/trees/objects that effectively make it 1/4 area.

Still, these deviations from the 1/4 area assumption were mentioned before. I don't think you read the thread properly because you keep bringing up "flaws" that were already discussed.

What if the object does not start close enough to have a region that is bilinear or with the 1.25 ratio?

Remember, I'm talking about average case. Some objects are only 1.25x, some only 5x, some have a blend of both, some have 1x as well. On average, though, the 1.25x objects are bigger than the 5x objects, because they are closer. Yet again, this was already discussed by Hyp-X when he brought up the same point.

If you average all objects on the screen, you get close to the 1/4 area weighting. I agree that it will be slightly lower than this in actuality though.

In this case, Trilinear covers EXACTLY 5x the texel area per filtered pixel. At every point, it samples the bilinear filter texel area plus the next more detailed mip level, which is always 4x the detail in texel count. Bilinear filtering is not defined as sampling the "closest" mip level, but rather the mip level that is less than or equal to the screen LOD.

Check some games, and you'll find that isn't the case. Compare bilinear and trilinear here. This was also the topic of discussion above.

Those games then are changing their LOD bias and introducing aliasing.

Well too bad, because that's what they do. Look anywhere. Quake 3. Serious Sam. UT2003.

There is a "1.25" bit. That's from observation of LOD transition points in the way graphics cards do things, not assumptions of how it should be.

You didn't read my post. My units are in AREA. Each mip level is a factor of 4 apart in AREA.

I don't see the difference. It's just a constant factor whether you are talking about what Hyp-X was talking about or what you were talking about. However, there is evidence that there is a 1.25 region as shown in my links, so your shift was not needed relative to bilinear.

Redefine n as you wish, its the relationship between bilinear and trilinear that we're after.

I'll respond to your assumptions:

First many objects are in the distance, and it can't be said that the required mip levels don't fit in cache for these. In other words, the whole texture mip pyramid need not fit in cache, only the sub pyramid for the object. Only a certain fraction of the screen is made up of large objects (in screenspace) that have large textures.

Okay, fine. Then beyond this mip-map we have about equal bandwidth requirements for both tri and bi, and on average the overall bandwidth premium of tri over bi is now lower.

The rest of your points I essentially agree with, but some of them don't have much to do with the bandwidth premium of tri over bi. We can't predict how much of a texture is magnified (tri is reduced to bi) or entirely cached (tri has almost identical bandwidth requirements as bi), so it's the rest that I'm after.


However, I just realized a rather BIG mistake in my calculations (how could you miss this, Hyp-X? ). It is from a "5x" region to the next "5x" region that the area becomes 1/4, not from a "5x" region to the next "1.25x" region. My series then should have been:

(1)*2*1.25+(1/2)*5+(1/4)*2*1.25+(1/8)*5+..... / (3.33) = 2.0

So again, we are back to the ratio of 2. Add in the cases where the area weighting is more than 1/4, and your ratio goes to somewhat above 2. Further adding the cases where tri and bi require the same bandwidth, and we are now probably well below 2.

If you still don't believe in the 1.25 region, clearly visible in the above links, then there's nothing I can do. I'll conclude by saying that in the regions where there is a difference between bi and tri bandwidth requirements, the ratio is a bit over 2, say 2.1. Overall, the ratio is much less than 2, maybe around 1.3. If I have time, I'll write a small program to examine these coloured screen shots so that we get a better idea of the area weightings.

In any case, it is rather hard to make any estimate of performance implications due to a myriad of factors.