Anisotropic filtering : Safe to assume with PS_2_0?

Started by
3 comments, last by violentrevolution 11 years, 3 months ago

Hi folks,

I have been using a (Min,Mag,Mip) all Linear, in my effects file. With a ps_2_0 compile option, can I assume that my GPU will always be capable to support Anisotropy? I know that it's always safer to define an alternate 2D sampler for anisotropy filtering, and use that technique when GPU caps indicate the anisotropic support. But isn't ps_2_0 already sort of ensuring those capabilities?

On a side note, I am observing a pixel-wide edge on top and left of my rendering window, which kinda looks like some sort of noise that is imitating the main window. Is this some filtering related issue or something else?

I am using direct3d9 APIs for rendering.

Advertisement
ps_2_0 does not guarantee anisotropic filtering capability, but in practice most ps 2.0-capable cards are capable of at least one degree of anisotropic filtering. Do remember that the maximum anisotropy degree (effectively, the root number of sample taps) is still variable, so you should check it anyway. Some drivers disable anisotropic filtering if you set the degree too high for the hardware, and this would cause visual quality issues.

Niko Suni

As for your side note:

-Are you drawing directly to the backbuffer or rendering via an intermediate texture?

-Do your render target dimensions exactly match the client area of the window (which is often not equal to the total window size)?

-If you do render to an intermediate render target before "blitting" to backbuffer, do you take into account the half-texel offset required to align the source and destination pixels 1 to 1?

Niko Suni

Thanks for the response Niko. About the Anisotropy deal, I am much more convinced about my approach to the filtering schemes, as per your suggestion.

For the side note, well I am simply rendering the local cam capture frames in windowed mode. There is no "blitting" involved, I am simply picking up the texture from the channel which is the one on which the captured frames are being delivered. As for the render target dimensions, I am doing a GetClientRect for calculating the backbuffer dimensions.

This one is a real puzzle for me now. I have been at it since months now, but can't seem to understand that why I am getting these noisy edges only on windows, but not on Mac (using OpenGL there), when my rendering flow is exactly the same for both platforms.

Btw, this issue got solved. I found out that pixel offsets were not being calculated properly for Vertices. Used the standard +1/height, -1/width correction logic and works well now. This thread may be marked as solved and closed now.

This topic is closed to new replies.

Advertisement